February 17, 2011 at 12:10 pm
I wanted to find out if there is any overhead involved in a possible implicit conversion if I compare a datetime and a smalldatetime. I think I've shown
Can anyone confirm or refute my logic and/or conclusions?
The process:
I created a temp table and populated it using my calendar table. The calendar table contains 1 row for each day from 1/1/1980 to 1/1/2079:
create table #implicit (cDate char(8),dtDate datetime,sdtDate smalldatetime)
insert into #implicit select convert(char(8),datege,112),datege,datege from mylibrary.dbo.calendardst
Temp table #implicit now contains 36161 rows. Then I fired up profiler and noodled around to only show my spid-- and ran the 3 queries shown below to see if a smalldatetime/datetime comparison causes an implicit convert.
The queries compare
QUERY: select case when cdate = dtdate then 'c eq dt' else 'c ne dt' end comp1 from #implicit
StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions
-------- ------ ------ ------ ---------- --------- -------- ------------- ------------ ---------- ----------- ---------- ---------------- ---------- -------- ---- -------- ------------------
Compute Scalar(DEFINE: ([Expr1004]=CASE WHEN CONVERT_IMPLICIT(datetime,[tempdb].[dbo].[#implicit].[cDate],0)=[tempdb].[dbo].[#implicit].[dtDate] THEN 'c eq dt' ELSE 'c ne dt' END)) 0 0 Compute Scalar Compute Scalar DEFINE: ([Expr1004]=CASE WHEN CONVERT_IMPLICIT(datetime,[tempdb].[dbo].[#implicit].[cDate],0)=[tempdb].[dbo].[#implicit].[dtDate] THEN 'c eq dt' ELSE 'c ne dt' END) [Expr1004]=CASE WHEN CONVERT_IMPLICIT(datetime,[tempdb].[dbo].[#implicit].[cDate],0)=[tempdb].[dbo].[#implicit].[dtDate] THEN 'c eq dt' ELSE 'c ne dt' END 36161 0 0.0036161 14 0.142231 [Expr1004] PLAN_ROW 0 1
|--Table Scan(OBJECT: ([tempdb].[dbo].[#implicit])) 0 1 0 Table Scan Table Scan OBJECT:([tempdb].[dbo].[#implicit]) [tempdb].[dbo].[#implicit].[cDate], [tempdb].[dbo].[#implicit].[dtDate] 36161 0.0987591 0.0398556 23 0.138615 [tempdb].[dbo].[#implicit].[cDate], [tempdb].[dbo].[#implicit].[dtDate] PLAN_ROW 0 1
QUERY: select case when cdate = sdtdate then 'c eq sdt' else 'c ne sdt' end comp2 from #implicit
StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions
-------- ------ ------ ------ ---------- --------- -------- ------------- ------------ ---------- ----------- ---------- ---------------- ---------- -------- ---- -------- ------------------
Compute Scalar(DEFINE: ([Expr1004]=CASE WHEN CONVERT_IMPLICIT(smalldatetime,[tempdb].[dbo].[#implicit].[cDate],0)=[tempdb].[dbo].[#implicit].[sdtDate] THEN 'c eq sdt' ELSE 'c ne sdt' END)) 0 0 Compute Scalar Compute Scalar DEFINE: ([Expr1004]=CASE WHEN CONVERT_IMPLICIT(smalldatetime,[tempdb].[dbo].[#implicit].[cDate],0)=[tempdb].[dbo].[#implicit].[sdtDate] THEN 'c eq sdt' ELSE 'c ne sdt' END) [Expr1004]=CASE WHEN CONVERT_IMPLICIT(smalldatetime,[tempdb].[dbo].[#implicit].[cDate],0)=[tempdb].[dbo].[#implicit].[sdtDate] THEN 'c eq sdt' ELSE 'c ne sdt' END 36161 0 0.0036161 15 0.142231 [Expr1004] PLAN_ROW 0 1
|--Table Scan(OBJECT: ([tempdb].[dbo].[#implicit])) 0 1 0 Table Scan Table Scan OBJECT:([tempdb].[dbo].[#implicit]) [tempdb].[dbo].[#implicit].[cDate], [tempdb].[dbo].[#implicit].[sdtDate] 36161 0.0987591 0.0398556 19 0.138615 [tempdb].[dbo].[#implicit].[cDate], [tempdb].[dbo].[#implicit].[sdtDate] PLAN_ROW 0 1
QUERY: select case when dtdate = sdtdate then 'dt eq sdt' else 'dt ne sdt' end comp3 from #implicit
StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions
-------- ------ ------ ------ ---------- --------- -------- ------------- ------------ ---------- ----------- ---------- ---------------- ---------- -------- ---- -------- ------------------
Compute Scalar(DEFINE: ([Expr1004]=CASE WHEN [tempdb].[dbo].[#implicit].[dtDate]=[tempdb].[dbo].[#implicit].[sdtDate] THEN 'dt eq sdt' ELSE 'dt ne sdt' END)) 0 0 Compute Scalar Compute Scalar DEFINE: ([Expr1004]=CASE WHEN [tempdb].[dbo].[#implicit].[dtDate]=[tempdb].[dbo].[#implicit].[sdtDate] THEN 'dt eq sdt' ELSE 'dt ne sdt' END) [Expr1004]=CASE WHEN [tempdb].[dbo].[#implicit].[dtDate]=[tempdb].[dbo].[#implicit].[sdtDate] THEN 'dt eq sdt' ELSE 'dt ne sdt' END 36161 0 0.0036161 15 0.142231 [Expr1004] PLAN_ROW 0 1
|--Table Scan(OBJECT: ([tempdb].[dbo].[#implicit])) 0 1 0 Table Scan Table Scan OBJECT:([tempdb].[dbo].[#implicit]) [tempdb].[dbo].[#implicit].[dtDate], [tempdb].[dbo].[#implicit].[sdtDate] 36161 0.0987591 0.0398556 19 0.138615 [tempdb].[dbo].[#implicit].[dtDate], [tempdb].[dbo].[#implicit].[sdtDate] PLAN_ROW 0 1
February 17, 2011 at 12:40 pm
Unfortunately your tests are quite fair. You need to have an index on a column so that you see if the implicit conversion causes a problem or not. You had nothing but table scans, so yes, it didn't affect performance. See if you get a problem when you have an index seek on a comparison without a conversion and then see if the implicit conversion causes a problem then (it frequently does, but not always, hence testing, which you're doing well already).
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 17, 2011 at 1:08 pm
Hi Grant-- thanks for the quick reply. (I think you meant "Unfortunately your tests are NOT quite fair")
Point taken regarding indexing. Let me ask a smaller question: The query plan shows "...CASE WHEN CONVERT_IMPLICIT..." on the first 2 queries but not on the third... so that pretty much clears use of smalldatetime and datetime in comparisons, doesn't it?
February 18, 2011 at 6:29 am
mstjean (2/17/2011)
Hi Grant-- thanks for the quick reply. (I think you meant "Unfortunately your tests are NOT quite fair")Point taken regarding indexing. Let me ask a smaller question: The query plan shows "...CASE WHEN CONVERT_IMPLICIT..." on the first 2 queries but not on the third... so that pretty much clears use of smalldatetime and datetime in comparisons, doesn't it?
In that instance yes. It really depends on the values used. I've seen implicit conversions between smalldatetime & datetime.
And yeah, that was a typo, glad you caught it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply