Re: Retiring is_pushed_down

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: Retiring is_pushed_down
Дата
Msg-id CAMbWs4-BGokURcVNDmEpQ8OG9Ur_2MP_+FVWRWb9OsC_DvX=4g@mail.gmail.com
обсуждение исходный текст
Ответ на Retiring is_pushed_down  (Richard Guo <guofenglinux@gmail.com>)
Ответы Re: Retiring is_pushed_down  (vignesh C <vignesh21@gmail.com>)
Список pgsql-hackers
Дерево обсуждения

On Tue, Jul 25, 2023 at 3:39 PM Richard Guo <guofenglinux@gmail.com> wrote:
* This patch calculates the outer join relids that are being formed
generally in this way:

    bms_difference(joinrelids, bms_union(outerrelids, innerrelids))

Of course this can only be used after the outer join relids has been
added by add_outer_joins_to_relids().  This calculation is performed
multiple times during planning.  I'm not sure if this has performance
issues.  Maybe we can calculate it only once and store the result in
some place (such as in JoinPath)?

In the v2 patch, I added a member in JoinPath to store the relid set of
any outer joins that will be calculated at this join, and this would
avoid repeating this calculation when creating nestloop/merge/hash join
plan nodes.  Also fixed a comment in v2.

Thanks
Richard
Вложения

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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Performance degradation on concurrent COPY into a single relation in PG16.
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan