November 26, 2010 at 3:55 am
Hello,
I need help on performance Improvement, I have large database where in i need to find the average days spend by one entity record. I have tried different ways, like using temp tables, using SQL functions like row_number but the performance is still very slow.
can anyone guide me for performance Improvement. I have attached test plan of the code that is taking more time.
November 26, 2010 at 5:27 am
A first quick look on the query plan provided shows that you have two heavy sort operations on:
[StudentTest].[dbo].[StudentHistory].StudentId Ascending,
[StudentTest].[dbo].[StudentHistory].StudentHistoryId Descending
These take 48% of the resource. You should have an index on that table:
CREATE UNIQUE NONCLUSTERED INDEX IX_StudentHistory_StudentId_StudentHistoryId
ON dbo.StudentHistory
(
StudentId ASC,
StudentHistoryId DESC
);
I suspect StudentId, StudentHistoryId together is unique, if not, you have to omit the UNIQUE clause.
Cheers
November 26, 2010 at 5:53 am
You are using the cte StudHistory multiple times , in this case this is hurting you.
Contrary to popular belief , cte are not spooled or cached in any way shape or form.
You can see that in the plan there are multiples evaluations of it.
I think you will make things easier is you manually spool the cte into a temp table first off then use that.
November 26, 2010 at 12:34 pm
yatish.patil (11/26/2010)
Hello,I need help on performance Improvement, I have large database where in i need to find the average days spend by one entity record. I have tried different ways, like using temp tables, using SQL functions like row_number but the performance is still very slow.
can anyone guide me for performance Improvement. I have attached test plan of the code that is taking more time.
I agree with both of the previous posts especially Dave's on the subject of cte's being executed once for each time called.
This is a classic example of where doing it all in one query isn't the best idea.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 27, 2010 at 5:46 am
Some other thoughts, you're trying to find the average number of days but you're returning 146,000 rows. Do you really need that much data? Reducing the amount moved around can help performance. And those scans on 1.7 million rows, those are killing you. Again, better filters in place to reduce the data being moved around could make a huge difference.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
November 30, 2010 at 3:59 am
Hello,
I tried to use temp table instead of CTE but the performance got even bad after using temp table instead of CTE. I will explain the inner block logic
consider below example
Historyid, id, changedate, subjectid, nextchangedate
===========================================
1,1, '06/30/2010',1,'07/01/2010'
2,1, '07/01/2010',1,'07/15/2010'
3,1, '07/15/2010',2,'07/31/2010'
4,1, '07/31/2010',3,'08/01/2010'
5,1, '08/01/2010',1,'08/31/2010'
6,1, '08/31/2010',1,'10/15/2010'
6,1, '10/15/2010',1,null
in this example i am trying to retrieve
1,1, '06/30/2010',1,'07/01/2010'
2,1, '07/01/2010',1,'07/15/2010'
3,1, '07/15/2010',2,'07/31/2010'
4,1, '07/31/2010',3,'08/01/2010'
and exclude all those records with subjectid 1 and nextchangedate is null until the old subject id in this example 3 at row no 4.
can anyone tell me if there is any chance to improve the inner code block.
December 2, 2010 at 4:23 am
Sorry , lost track of this one,
There does seem room for improvement here, Im not 100% clear on your requirements though.
Can you try restating and clarifying ?
December 3, 2010 at 12:28 pm
Hello,
I tried to use temp table instead of CTE but the performance got even bad after using temp table instead of CTE. I will explain the inner block logic
After creating and populating the temp table, look at the query plan for the next step.
I am guessing adding an index to the temp table would help.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply