Re: Slow execution of a stored procedure
From: pep_castefa (pepcastefa_at_discussions.microsoft.com)
Date: 02/17/05
- Next message: Damon: "Help woth stored procedure!"
- Previous message: mark baekdal: "RE: alter column with PK / index"
- In reply to: Uri Dimant: "Re: Slow execution of a stored procedure"
- Next in thread: Uri Dimant: "Re: Slow execution of a stored procedure"
- Reply: Uri Dimant: "Re: Slow execution of a stored procedure"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 17 Feb 2005 01:01:03 -0800
I have discovered something... the first time I execute the SP the variable
'physical reads' is high (a lot of reads from physical disk). All the other
executions have this variable to 0. Does that mean it has all the 1.300.000
rows in memory? If so, is there any way to initialize this table in memory
the first time SQL Server executes? (there is an ugly way, which would be
executing the SP the first time SQL starts just to make it bring the table to
memory...)
By the way, Uri... the table doesn't have many columns. I dont think that is
the problem.
What I have seen in the execution plan is that it first uses a clustered
index seek, then it filters the values. The clustered index seek is because
the SP I wrote for this post was not really the one Im using. The one Im
using in production has a JOIN with another table. What I dont know is if it
would be better to do the filter first (passing from 1.300.000 registers to
no more than 50), using the index, and then do the clustered index seek (to
do the join with the other table). Is there any way to tell SQL Server to do
the filtering first and then the JOIN?
- Next message: Damon: "Help woth stored procedure!"
- Previous message: mark baekdal: "RE: alter column with PK / index"
- In reply to: Uri Dimant: "Re: Slow execution of a stored procedure"
- Next in thread: Uri Dimant: "Re: Slow execution of a stored procedure"
- Reply: Uri Dimant: "Re: Slow execution of a stored procedure"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|