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
|
| Список | 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
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 по дате отправления: