I had a question from a reader about contradiction detection.<\/p>\n
The basic idea is to determine that this kind of query:<\/p>\n
SELECT * FROM TABLE WHERE col1 > 5 and col1 < 0;<\/p>\n
…is utterly meaningless and requires no work to be done. It will always return zero rows. In fact, in many cases the SQL Server QP will detect cases like this and actually remove the table from the query completely. In its place, you have this magical “constant scan” operator, which is really just an in-memory row generator. So, you can read from it instead of from a table.<\/p>\n
This optimization is done in many places in the SQL Server QP, and it is great because it requires no I\/O, no locks, and less CPU than actually reading from a table.<\/p>\n
The question I had from a user had to do with cases when this optimization does NOT happen.<\/p>\n
Since the reader sent me a perfect example, I’ll just copy it up here (note – I am happy to credit readers if they would like credit, but I don’t post their name unless they want me to do so).<\/p>\n
–drop table #tmp create<\/span> table<\/span> #tmp <\/span>(<\/span>id Int<\/span> Identity<\/span>(<\/span>1,<\/span>1)<\/span> Primary<\/span> key<\/span>,<\/span> name VarChar<\/span>(<\/span>250)) go insert<\/span> into<\/span> #tmp(<\/span>name)<\/span> values<\/span>(<\/span>NEWID<\/span>()) insert<\/span> into<\/span> #tmp(<\/span>name)<\/span> values<\/span>(<\/span>NEWID<\/span>()) go set<\/span> statistics<\/span> profile<\/span> on go — Execution plan create a Constant Scan select<\/span> *<\/span> from<\/span> #tmp where<\/span> id =<\/span> 1 and<\/span> id =<\/span> 5 go set<\/span> statistics<\/span> profile<\/span> off GO select * from #tmp where id = 1 and id = 5 –drop table tmp create<\/span> table<\/span> tmp <\/span>(<\/span>id Int<\/span> Identity<\/span>(<\/span>1,<\/span>1)<\/span> Primary<\/span> key<\/span>,<\/span> name VarChar<\/span>(<\/span>250)) go insert<\/span> into<\/span> tmp(<\/span>name)<\/span> values<\/span>(<\/span>NEWID<\/span>()) insert<\/span> into<\/span> tmp(<\/span>name)<\/span> values<\/span>(<\/span>NEWID<\/span>()) go set<\/span> statistics<\/span> profile<\/span> on — Why execution plan does not create a select<\/span> *<\/span> from<\/span> tmp where<\/span> id =<\/span> 1 and<\/span> id =<\/span> 5 go set<\/span> statistics<\/span> profile<\/span> off<\/span><\/span> SELECT * FROM [tmp] WHERE [id]=@1 AND [id]=@2 <\/p>\n So this is interesting – in one case the constant scan is done, while in the other case it is not…. hrm. what’s up with that?<\/p>\n Well, some of you are familiar with autoparameterization – a feature that can take unparameterized queries, try to make them parameterized, and then avoid compilation for multiple similar simple queries. Autoparameterization is tied to the “trivial plan” feature, meaning that the optimizer feels that there isn’t really a plan choice and thus going through the complete cost-based optimization process is unnecessary.<\/p>\n The difference you see is based on autoparameterization and whether it happens or not. Now, the autoparameterization rules are fairly arcane at this point – they’ve been around, in some form, for various releases dating back to SQL 7.0. TempDB has a different set of rules about whether a query should be autoparameterized since these tables are globally shared. So, in the #tmp case the table isn’t being autoparameterized, the rest of the logic to simplify the query is run, and this rule detects the contradiction.<\/p>\n In the latter case, the query IS auto-parameterized. The optimizer doesn’t see two parameters as always being a contradiction (you could pass the same value for both parameters), and then the query is not simplified.<\/p>\n For what it is worth, a somewhat internal knowledge of what causes a plan to be considered trivial or not can influence whether you see one plan or the other. For example, query hints make a plan not trivial (why hint if there is no plan choice?), and as such you could do something like this:<\/p>\n select * from tmp This will get you the constant scan in all databases. Adding enough rows to get the cost above the threshold for parallelism (in a parallel-enabled machine + SKU of SQL) would also do it. <\/p>\n Remember, trivial plan was developed before contradiction detection, so this should be viewed in that context. It’s a bit odd, but the ecosystem developed this way and you should be aware of that when developing SQL Server apps.<\/p>\n I enjoy the questions – keep them coming!<\/p>\n Thanks, <\/p>\n","protected":false},"excerpt":{"rendered":" I had a question from a reader about contradiction detection. The basic idea is to determine that this kind of query: SELECT * FROM TABLE WHERE col1 > 5 and col1 < 0; …is utterly meaningless and requires no work to be done. It will always return zero rows. In fact, in many cases the […]<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-392","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"yoast_head":"\n
|–Constant Scan
<\/o:p><\/span><\/p>\n
\nConstant Scan for this case?
|–Clustered Index Seek(OBJECT:([t1].[dbo].[tmp].[PK__tmp__3213E83F15502E78]), SEEK:([t1].[dbo].[tmp].[id]=CONVERT_IMPLICIT(int,[@1],0)), WHERE:([t1].[dbo].[tmp].[id]=CONVERT_IMPLICIT(int,[@2],0)) ORDERED FORWARD)<\/p>\n
where id = 1 and id = 5 option (maxdop 1)<\/p>\n
Conor<\/p>\n