|
|
|
SSC Veteran
 
Group: General Forum Members
Last Login: Friday, March 12, 2010 5:53 PM
Points: 207,
Visits: 151
|
|
Hi Randy,
Thanks for the article. We also had similar issues joining two three tables with over 200 Million rows with WHERE condition, the O/P was dying if we used derived tables or JOINS. But once we started using #temp tables pre-populated with where conditions the queries executed in seconds.
I think execution manager in SQL Server 2005 in not efficiently managing the worker tables or derived tables when the dataset is huge.
Regards,
Razi, M.
http://questivity.com/it-training.html
|
|
|
|
|
SSChampion
Group: Administrators
Last Login: Today @ 8:44 PM
Points: 23,132,
Visits: 6,900
|
|
SQL Server 2005 handles most code better, but not all.
If you are having performance issues, I suggest you post a more details explanation in the SQL Server 2005 Performance Tuning Forum.
|
|
|
|
|
Grasshopper
Group: General Forum Members
Last Login: Thursday, October 15, 2009 2:37 AM
Points: 17,
Visits: 100
|
|
> I am not fond of cursors and advocate doing anything possible to replace the cursor
What do you gain by handling the looping yourself rather than just using a cursor? I try and get rid of cursors by replacing with a single sql statement. Obviously this won't work if you have to call a stored procedure for every record in a table (for example), but if you have to do this then why is using your own looping mechanism preferable to using a cursor?
|
|
|
|
|
SSChampion
Group: General Forum Members
Last Login: Today @ 10:58 PM
Points: 20,139,
Visits: 13,678
|
|
alex (5/15/2009)
> I am not fond of cursors and advocate doing anything possible to replace the cursor
What do you gain by handling the looping yourself rather than just using a cursor? I try and get rid of cursors by replacing with a single sql statement. Obviously this won't work if you have to call a stored procedure for every record in a table (for example), but if you have to do this then why is using your own looping mechanism preferable to using a cursor?
I agree... a good "firehose" cursor makes sense here.
--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
