Comments on: Eliminate the Use of Temporary Tables For HUGE Performance Gains

By: blah

blah — Thu, 19 Apr 2012 18:28:12 +0000

I’ll ditto what others have said. I use both derived and temp tables. I run a bunch of procedures start-of-day to double-check some info. In cases where it’s a small list of stuff to compile for reference, a derived table works like a charm. But, I found noticeable improvements when I decided to pre-compile a lot of aggregate data early as temp tables which are used in a lot of later queries. I don’t just make #temp tables, though, I make actual tables in the tempdb. I use them through-out the day while working on other queries, or ad-hoc’ing something on request. The checks I run used to take 5 minutes total every day. After I started temp tableing larger things, it’s down to 1:30, and that includes the time to temp-table the stuff. As for wear-n-tear on disk I/O and things … when I do the math for how much time I’m saving, times by how much I get paid by minute … the company can afford a little wear-n-tear on a hard drive compared to me twiddling my thumbs for an extra 3:30. (Besides, that 3:30 is enough time for me to get distracted in something else, which kills productivity totally.)

By: Ayan Sengupta

Ayan Sengupta — Wed, 11 Jan 2012 12:49:41 +0000

I think the exact opposite for general sql server queries. I have tried a query returning around 7000 rows both using temporary table(even without index) and using derived table.

The difference is significant. Using temporary table takes literally 0ms while the derived table version takes at least 17ms.

One of the bottleneck of the temporary table is of course the locking over entire tempdb. But it never implies that we should avoid that. I suggestion is to use temporary table whenever possible only keeping the locking issue under consideration.

By: Marcel Drost

Marcel Drost — Mon, 12 Dec 2011 10:28:53 +0000

I have the same experience with Derived tables (Subqueries).

An average select query performs nicely when retrieving all 82000 rows. Execution time is 1 second.

Then I was asked to sum 1 column and to group it on the 2 remaining integer columns.

I tried a derived table, Sum the main query and a temp table.

The Temp Table keeps it in 1 second. The other 2 solutions are within 4/5 minutes.

Thus my question; has any1 have any experience of forcing the query execution plan of the derived table?

By: John

John — Mon, 21 Nov 2011 14:40:18 +0000

I agree with Joe as we have experienced the exact opposite effect with large result sets and fairly complex aggregation queries (derived tables) joining against each other. We eliminated the use of derived tables by placing the data into temp tables and took a query that was running for close to 11 hours down to running under 11 seconds. The execution plan indicated the optimizer had no idea what to expect from the derived tables as the actual number of rows was very different from the estimated number of rows.

By: Nian

Nian — Mon, 21 Nov 2011 11:24:34 +0000

This is completely misleading. Everything exists for a reason or MS wouldn’t have invented temp tables. Derived tables are good for small quantity of data and select operation. When the data volumn is huge and often combined with operations like Group by, temp table can be lot faster by creating and using indexes.

By: Joe Harris

Joe Harris — Wed, 02 Nov 2011 11:39:46 +0000

This advice is ONLY applicable to OLTP workloads (e.g., small quick transactions). SQL Server “derived tables” (subqueries to everyone else) are **highly** optimised for small SELECTs.

In a DW / ETL / OLAP type workloads the exact **opposite** advice applies. In DW processing I often see HUGE performance gains from converting selects to temp tables.