July 6, 2005 at 9:39 am
Sub: My doubt is regarding the usage of temporary Tables
The scenario is I was checking the difference in execution time
of the usage of temporary tables and table variables in 2
different procedures.
When I checked the Estimated Execution Plan on the procedure
with the table variable it displayed it fine.
But when i checked the Estimated Execution Plan on the procedure
with temporary table it displayed error specifying the name of
the temporary table.
Are temporary tables not to be used when displaying estimated
execution plan.
Can anyone point out, what would be the reason for that error.
regards
shown
July 6, 2005 at 9:44 am
You're right, only the 2nd part of this query fails on estimated query plan.
Declare @a table (name varchar(50) not null primary key)
Select * from @a
GO
Create table #a (name varchar(50) not null primary key)
Select * from #a
DROP TABLE #a
Looks like you have to execute the query to fetch the actual plan.
July 6, 2005 at 9:51 am
Mr Remi,
I didn't get u'r last sentence.
Please will U make it more clear.
regards
shown
July 6, 2005 at 9:53 am
You can't use the estimated query plan when you have a temp table. You have to execute the query and see the real execution plan (ctrl-k) to see which one is fasted.
July 6, 2005 at 9:58 am
Wasn't there a thread (or two) recently on temp tables vs. table variables? I recall the gist was SQL Server implements them similarly, so you don't really get any perf benefits with one or the other, except where the use of an index would help.
July 6, 2005 at 9:58 am
That means we can use it with real execution plan but not
with Estimated Plan.
Is it being set like that for some hidden reason.Or is it a bug
in SQL SERVER.
regards
shown
July 6, 2005 at 10:01 am
The question is about estimated execution plan... The performance question will surely come in later .
July 6, 2005 at 10:06 am
And no is not a bug is "by design"
Well to be fair the execution plan with tem tables will be dependent on how many rows (Inserts /Updates/deletes) are affecting that table which is not known until run time. If it varies a lot from one run to the next, procedure recompilations take place (where you may get a new plan )
* Noel
July 6, 2005 at 10:06 am
Mr Dave,
The main reason I used this performance checking was because I
actually so an article in SQLSERVERCENTRAL
"The ARRAY In SQL Server 2000" by Mr.Alex Grinberg
saying Table variables are faster than Temporary tables.
regards
shown
July 6, 2005 at 10:09 am
Not necessarily so
have a look: http://support.microsoft.com/default.aspx?scid=kb;en-us;305977
* Noel
July 6, 2005 at 10:10 am
Here's a recent discussion on the topic we had recently :
http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=120&messageid=182804
July 6, 2005 at 10:40 am
I am honoured to be a part of this discussion on the
performance of table variables and temporary tables.
Thank U very much for the feedback,as i have cleared a
doubt and studied something new.
From this I have studied something else too.That is
not to believe or study something just by seeing a single
article.
regards
shown
July 6, 2005 at 10:47 am
You got that right .
July 7, 2005 at 8:12 am
I would agree that table variables will *USUALLY* be better than temp tables, the original question was about getting an execution plan.
You can't get an execution plan for a table that doesn't exist. If your batch includes CREATE TABLE (temp or otherwise), you have to execute the CREATE TABLE statement to be able to get an execution plan for the commands that refer to the table.
July 7, 2005 at 2:58 pm
But once you have created your temp table, before you get your execution plan, be sure to go through the steps to populate the table. Otherwise the optimizer won't give you realistic results (ran across this once when a developer was scratching his head trying to find a performance bottleneck in an SP).
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply