January 18, 2012 at 4:33 pm
Hi,
If we create Temporay Tables in a Stored Procedure will degrade the performance of the query?
Ex:
CREATE TABLE #TempTable
(id int,name varchar(50))
INSERT INTO #TempTable
SELECT id,name FROM Employee
How to improve the performance of stored procedure while using temporary tables?
Thanks,
Suresh
January 19, 2012 at 1:19 am
suresh0534 (1/18/2012)
Hi,If we create Temporay Tables in a Stored Procedure will degrade the performance of the query?
Maybe, or maybe it'll improve the performance due to been able to process smaller chunks of data. You should probably only use them when they do improve things
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 20, 2012 at 6:56 am
suresh0534 (1/18/2012)
Hi,If we create Temporay Tables in a Stored Procedure will degrade the performance of the query?
Ex:
CREATE TABLE #TempTable
(id int,name varchar(50))
INSERT INTO #TempTable
SELECT id,name FROM Employee
How to improve the performance of stored procedure while using temporary tables?
Thanks,
Suresh
I have gotten 4+ orders of magnitude performance improvement by adding temporary table(s) to a stored procedure. I have also gotten 4+ orders of magnitude performance improvement by REMOVING temporary table(s) from a sproc. There is no right answer and doing this type of refactoring/tuning isn't something that can be covered in a few forum posts. Sorry...
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
January 20, 2012 at 7:16 am
Hi,
You can also use table variables for better performance but it has some limitations like,
1. Transaction logs are not recorded for the table variables. Hence, they are out of scope of the transaction mechanism
2. Any procedure with a temporary table cannot be pre-compiled, while an execution plan of procedures with table variables can be compiled in advance.
3. Table variables exist only in the same scope as variables
January 20, 2012 at 7:32 am
deepkt (1/20/2012)
1. Transaction logs are not recorded for the table variables. Hence, they are out of scope of the transaction mechanism
Half true. They are out of transaction scope, but that does not mean that they are unlogged. They are logged like any other operations
2. Any procedure with a temporary table cannot be pre-compiled, while an execution plan of procedures with table variables can be compiled in advance.
Stored procedures are never pre-compiled. Execution plans are created on first execution only and remain until invalidated or removed from cache. In SQL 2000 temp tables did always cause recompiles, not the case in 2005 or above.
You also neglected to mention the severe performance implication (in a bad way) from the lack of statistics on table variables. They should be avoided if the correct costing of execution plans is even a consideration.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 23, 2012 at 11:07 am
If you are doing a lot of Temp table operations. You can improve performance by moving the TempDB files to a different drive and Create multiple files as oppose to one.
This is not a direct answer but it will help on a large scale.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply