Re: [HACKERS] Performance improvement for joins where outer side is unique

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Performance improvement for joins where outer side is unique
Дата
Msg-id 8444.1485812605@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Performance improvement for joins where outer side is unique  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: [HACKERS] Performance improvement for joins where outer side is unique  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 31 January 2017 at 04:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not following.  If the join removal code had reached the stage of
>> making a uniqueness check, and that check had succeeded, the join would be
>> gone and there would be no repeat check later.  If it didn't reach the
>> stage of making a uniqueness check, then again there's no duplication.

> I had forgotten the unique check was performed last. In that case the
> check for unused columns is duplicated needlessly each time.

I think we do need to repeat that each time, as columns that were formerly
used in a join condition to a now-dropped relation might thereby have
become unused.

> But let's
> drop it, as putting the code back is not making things any worse.

Agreed, if there is something to be won there, we can address it
separately.

> I don't think that's possible. The whole point that the current join
> removal code retries to remove joins which it already tried to remove,
> after a successful removal is exactly because it is possible for a
> join to become provability unique on the removal of another join.

Not seeing that ... example please?

> If you remove that retry code, a regression test fails.

Probably because of the point about unused columns...
        regards, tom lane



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Declarative partitioning - another take
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)