Re: hashjoin chosen over 1000x faster plan

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: hashjoin chosen over 1000x faster plan
Дата
Msg-id 1192042863.4233.340.camel@ebony.site
обсуждение исходный текст
Ответ на Re: hashjoin chosen over 1000x faster plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Wed, 2007-10-10 at 14:07 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > Basically the planner doesn't ever optimise for the possibility of the
> > never-executed case because even a single row returned would destroy
> > that assumption.
>
> It's worse than that: the outer subplan *does* return some rows.
> I suppose that all of them had NULLs in the join keys, which means
> that (since 8.1 or so) nodeMergejoin discards them as unmatchable.
> Had even one been non-NULL the expensive subplan would have been run.

Yup

> This seems like too much of a corner case to justify adding a lot of
> machinery for.

Well, I thought about that and it is pretty common to have root classes
left outer joined to sub-classes, if you are using the One Table per
Subclass object-relational mapping. The joined-subclass mapping within
Hibernate implements this.

Not everybody uses that, but it is an option some people take in some
circumstances. So we should keep it on our radar if we want to extend
our for support complex applications.

--
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


В списке pgsql-performance по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: hashjoin chosen over 1000x faster plan
Следующее
От: Theo Kramer
Дата:
Сообщение: Re: Performance problems with prepared statements