My today’s blog post is focused on the correct cardinality estimation for table variable using trace flag 2453. In one of my previous blog post, we have seen the use of OPTION (RECOMPILE) query hint for correct cardinality estimation in case of table variable. Now the question is, Is there any way to make the correct estimation of table variables without touching the TSQL code?
The answer of the above question is: yes, the optimizer can make a correct cardinality estimation for table variables without changing the TSQL code. We have to use trace flag 2453 for that. Using this trace flag is almost similar to option recompile and even sometime it performs better. Let me show you the impact of this trace flag practically. Here in my code, I am enabling the trace flag for my session only. If you want to enable it for all the session every time (even after the service restarts) then you can add it to the service startup parameters. For more information about that, you can click here.
/* This TF was introduced in SQL Server 2012 SP2 and SQL Server 2014 CU3*/ USE [AdventureWorks2016] GO DBCC TRACEON(2453) Declare @TV_SalesOrderDetail Table ( [SalesOrderID] [int] NOT NULL, [SalesOrderDetailID] [int] NOT NULL, [CarrierTrackingNumber] [nvarchar](25) NULL, [OrderQty] [smallint] NOT NULL, [ProductID] [int] NOT NULL, [SpecialOfferID] [int] NOT NULL, [UnitPrice] [money] NOT NULL, [UnitPriceDiscount] [money] NOT NULL, [LineTotal] [money], [rowguid] [uniqueidentifier] ROWGUIDCOL, [ModifiedDate] [datetime] NOT NULL ) INSERT INTO @TV_SalesOrderDetail SELECT [SalesOrderID] ,[SalesOrderDetailID] ,[CarrierTrackingNumber] ,[OrderQty] ,[ProductID] ,[SpecialOfferID] ,[UnitPrice] ,[UnitPriceDiscount] ,[LineTotal] ,[rowguid] ,[ModifiedDate] FROM [Sales].[SalesOrderDetail] Select SOD.UnitPrice, SOH.DueDate, SOH.OrderDate from @TV_SalesOrderDetail SOD join [Sales].[SalesOrderHeader] SOH on sod.SalesOrderID=SOH.SalesOrderID Where SOH.OrderDate between '2011-07-01' AND '2011-07-31' GO DBCC TRACEOFF(2453) GO
In the above image you can see that both estimated and actual number of rows are same.
Prince Kumar Rastogi
Like us on FaceBook | Join the fastest growing SQL Server group on FaceBook
Follow Prince Rastogi on Twitter | Follow Prince Rastogi on FaceBook