| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Emre Hasegeli <emre(at)hasegeli(dot)com> |
| Subject: | Re: Using each rel as both outer and inner for JOIN_ANTI |
| Date: | 2023-04-06 06:40:15 |
| Message-ID: | CAMbWs48TAs+65GsK989jXKG6cmcD3yRwa0P910sXobzmuQ9UdQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 6, 2023 at 1:06 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2023-04-06 06:40:57 | Re: Minimal logical decoding on standbys |
| Previous Message | Masahiko Sawada | 2023-04-06 06:39:43 | Re: Should vacuum process config file reload more often |