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