Re: Optimization rules for semi and anti joins

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Optimization rules for semi and anti joins
Дата
Msg-id 25300.1234303412@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Optimization rules for semi and anti joins  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Optimization rules for semi and anti joins  (Robert Haas <robertmhaas@gmail.com>)
Re: Optimization rules for semi and anti joins  (Greg Stark <greg.stark@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Optimization rules for semi and anti joins
Следующее
От: "David Rowley"
Дата:
Сообщение: The testing of multi-batch hash joins with skewed data sets patch