Is a Temporary Table Really Necessary?

Click here to monitor SSC

<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>

SQLServerCentral is supported by Red Gate Software Ltd.

Log in :: Register :: Not logged in

<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>

Recent Posts

Popular Topics

Home

Home » Article Discussions » Article Discussions by Author » Discuss Content Posted by Randy Dyess » Is a Temporary Table Really Necessary?

Add to briefcase

94 posts, Page 10 of 10

«««6 7 8 9 10

Is a Temporary Table Really Necessary?

Expand / Collapse

Author

Message

Posted Thursday, March 12, 2009 5:09 PM

SSC Veteran

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 2:37 PM
Points: 214, Visits: 166

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

Post #674840

Steve Jones - SSC Editor

Posted Thursday, March 12, 2009 5:38 PM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 2:54 PM
Points: 31,410, Visits: 13,726

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.

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #674856

Posted Friday, May 15, 2009 4:40 AM

Grasshopper

Group: General Forum Members
Last Login: Monday, May 24, 2010 2:28 AM
Points: 18, Visits: 102

> 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?

Post #717741

Posted Friday, May 15, 2009 8:12 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 5:33 PM
Points: 32,902, Visits: 26,783

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 on T-SQL questions, 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/

Post #717941

« Prev Topic | Next Topic »

Add to briefcase

94 posts, Page 10 of 10

«««6 7 8 9 10

Permissions

Expand / Collapse