March 12, 2009 at 5:09 pm
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
March 12, 2009 at 5:38 pm
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.
May 15, 2009 at 4:40 am
> 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?
May 15, 2009 at 8:12 am
alex (5/15/2009)
> I am not fond of cursors and advocate doing anything possible to replace the cursorWhat 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
Change is inevitable... Change for the better is not.
Viewing 4 posts - 91 through 93 (of 93 total)
You must be logged in to reply to this topic. Login to reply