Re: Using each rel as both outer and inner for JOIN_ANTI

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: Using each rel as both outer and inner for JOIN_ANTI
Дата
Msg-id CAMbWs48TAs+65GsK989jXKG6cmcD3yRwa0P910sXobzmuQ9UdQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Using each rel as both outer and inner for JOIN_ANTI  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Using each rel as both outer and inner for JOIN_ANTI  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
Дерево обсуждения

On Thu, Apr 6, 2023 at 1:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
This:

> +#if 0
>         /* If any limit was set to zero, the user doesn't want a
> parallel scan. */
>         if (parallel_workers <= 0)
>                 return;
> +#endif

seems like it adds a lot of new paths with a lot lower chance
of win, but maybe we could tighten the conditions to improve
the odds?

Seems it wins if the parallel scan becomes part of a hash join in final
plan.  I wonder if we have a way to know that in this early stage.

BTW, zero parallel_workers seems would break some later assumptions, so
we may need to give it a meaningful number if we want to do in this way.

Thanks
Richard

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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Should vacuum process config file reload more often
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Minimal logical decoding on standbys