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

From Tom Lane
Subject Re: Optimization rules for semi and anti joins
Date
Msg-id 25300.1234303412@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimization rules for semi and anti joins  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Optimization rules for semi and anti joins
Re: Optimization rules for semi and anti joins
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I don't understand why antijoins need to null-extend the tuple at all.

Well, we are talking theoretical definition here, not implementation.
But if you need an example where the column values can be referenced:
select * from a left join b on (a.id = b.id)where b.id is null

8.4 does recognize this as an antijoin, if the join operator is strict.

> 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.

Actually, that makes less sense than the antijoin case.  For antijoin
there is a well-defined value for the extended columns, ie null.  For
a semijoin the RHS values might come from any of the rows that happen
to join to the current LHS row, so I'm just as happy that it's
syntactically impossible to reference them.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Optimization rules for semi and anti joins
Next
From: "David Rowley"
Date:
Subject: The testing of multi-batch hash joins with skewed data sets patch