Horton

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

Richard Guo <guofenglinux@gmail.com>

View thread View on postgr.es
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, "Gregory Stark (as CFM)" <stark.cfm@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Ronan Dunklau <ronan.dunklau@aiven.io>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Emre Hasegeli <emre@hasegeli.com>
Date: 2023-04-06T06:40:15Z
Lists: 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

Commits

  1. Support "Right Anti Join" plan shapes.