Re: Optimization rules for semi and anti joins - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Optimization rules for semi and anti joins
Date
Msg-id 603c8f070902101351i41077552j780054bf36c50654@mail.gmail.com
Whole thread Raw
In response to Optimization rules for semi and anti joins  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Optimization rules for semi and anti joins  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> A6.     (A antijoin B on (Pab)) leftjoin C on (Pbc)
>        = A antijoin (B leftjoin C on (Pbc)) on (Pab)
>
> The second form is in fact equivalent to null-extending the A/B antijoin
> --- the actual contents of C cannot affect the result.  So we could just

I don't understand why antijoins need to null-extend the tuple at all.It seems that it would be cheaper and all-around
simplerto just pass
 
through the left-hand tuple unchanged.

In the case of a semijoin, it's theoretically possible that there
could be syntax which allows access to the attributes of the outer
side of the relation, though IN and EXISTS do not.  But with an
antijoin that's just nonsense, so I don't quite understand why we're
handling it as we are.

...Robert


pgsql-hackers by date:

Previous
From: "David Rowley"
Date:
Subject: Bug #4284
Next
From: Tom Lane
Date:
Subject: Re: Optimization rules for semi and anti joins