|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 10:33 AM
Points: 10,989,
Visits: 10,529
|
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 10:33 AM
Points: 10,989,
Visits: 10,529
|
|
I couldn't include a graphic in the answer, so here's the query and execution plan:
DECLARE @A TABLE (a INT NOT NULL UNIQUE) DECLARE @B TABLE (b INT NOT NULL)
SELECT COUNT_BIG(*) FROM @A RIGHT LOOP JOIN @B ON [@B].b = [@A].a

Notice the plan does not touch table @A.
Paul White SQL Server MVP SQLblog.com @SQL_Kiwi
|
|
|
|
|
SSCoach
         
Group: General Forum Members
Last Login: Thursday, May 16, 2013 1:46 PM
Points: 18,732,
Visits: 12,329
|
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: 2 days ago @ 4:56 AM
Points: 1,256,
Visits: 4,253
|
|
| This is one of those questions where the common sense answer (e.g. both tables have no data in, so of course the answer will be zero rows!) is actually right...I knew nothing about the stuff explained in the answer, so I learned something today.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: 2 days ago @ 7:47 AM
Points: 1,400,
Visits: 6,886
|
|
I normally don't comment on QOD articles, but the explanation and screen-shot of the execution plan deserves merit.
BrainDonor Linkedin
|
|
|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Saturday, March 16, 2013 9:53 AM
Points: 847,
Visits: 768
|
|
Indeed, the question and the explanation are great.
Thank you, Iulian
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 3:44 PM
Points: 1,786,
Visits: 3,323
|
|
Got it wrong (yes, I didn't run the code)  Excellent question which shows how the query optimizer works.
A similar example is how the INNER JOIN is removed (resulting in only a scan on table "child") in the following example, due to the fact that parent_id cannot be NULL and has a FK reference to table "parent".
create table parent(id int primary key) create table child(id int primary key, parent_id int not null references parent(id))
select c.* from dbo.child c inner join parent p on p.id = c.parent_id
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 10:33 AM
Points: 10,989,
Visits: 10,529
|
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 6:38 PM
Points: 7,077,
Visits: 7,116
|
|
Excellent question and explanation.
But it makes the behaviour in the first right join question seem even more bizarre than it seemed before. In this case there's a query that by very simple but not blindingly obvious reasoning can be shown to be equivalent to the original query and eliminates right loop join, and despite that lack of blinding obviousness the optimiser does the transformation and provides a plan. In the first case there's a blindingly obvious equivalent query (using left join) that doesn't run into the "no loop with right join" restriction, and the optimiser doesn't do the transformation despite the total obviousness. Not only is the statement in BoL misleading, and the actual behaviour with right loop inconsistent, but also the optimiser's choice of when to produce a plan and when not seems perverse! Or actually, it's the whole concept of "no loop with right join" that is ridiculous and perverse, because every right join is (trivially) equivalent to a left join, and there's no "no loop with left join" restriction - to make any sense at all the restriction would have to be purely syntactic, with no semantic content, but this QoTD demonstrates that it is not a syntactic restriction.
Tom Que conclure à la fin de tous mes longs propos? C'est que les préjugés sont la raison des sots. (Voltaire, 1756)
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 10:33 AM
Points: 10,989,
Visits: 10,529
|
|
Hi Tom,
The third question in this series will be published next week (8 September). I promise your question will be answered then.
Paul
Paul White SQL Server MVP SQLblog.com @SQL_Kiwi
|
|
|
|