Re: [HACKERS] OUTER JOIN performance regression remains in 8.3beta4

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: [HACKERS] OUTER JOIN performance regression remains in 8.3beta4
Дата
Msg-id 871w8rlzd4.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: [HACKERS] OUTER JOIN performance regression remains in 8.3beta4  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-patches
"Alvaro Herrera" <alvherre@commandprompt.com> writes:

> Tom Lane wrote:
>
>> Comparing the behavior of this to my patch for HEAD, I am coming to the
>> conclusion that this is actually a *better* planning method than
>> removing the redundant join conditions, even when they're truly
>> rendundant!  The reason emerges as soon as you look at cases involving
>> more than a single join.  If we strip the join condition from just one
>> of the joins, then we find that the planner insists on doing that join
>> last, whether it's a good idea or not, because clauseful joins are
>> always preferred to clauseless joins in the join search logic.
>
> Would it be a good idea to keep removing redundant clauses and rethink
> the preference for clauseful joins, going forward?

I don't understand what's going on here. The planner is choosing one join
order over another because one join has more join clauses than the other? Even
though some of those joins are entirely redundant and have no selectivity?
That seems like a fortuitous choice made on entirely meaningless data.

Is there some other source of data we could use to make this decision instead
of the number of clauses? I would suggest the selectivity but from the sound
of it that's not going to help at all.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's RemoteDBA services!

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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] Archiver behavior at shutdown
Следующее
От: Tom Lane
Дата:
Сообщение: Revised patch for fixing archiver shutdown behavior