Re: Using each rel as both outer and inner for JOIN_ANTI - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Using each rel as both outer and inner for JOIN_ANTI
Date
Msg-id CA+hUKG+cQroWxxt-8-fGNBPotABQbHG4aD9vNZ5hhyyF_cH-4g@mail.gmail.com
Whole thread Raw
In response to Re: Using each rel as both outer and inner for JOIN_ANTI  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Using each rel as both outer and inner for JOIN_ANTI  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Apr 6, 2023 at 12:17 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> I tried the original example from the top of this thread and saw a
> decent speedup from parallelism, but only if I set
> min_parallel_table_scan_size=0, and otherwise it doesn't choose
> Parallel Hash Right Anti Join.  Same if I embiggen bar significantly.
> Haven't looked yet but I wonder if there is some left/right confusion
> on parallel degree computation or something like that...

Ahh, the problem is just that create_plain_partial_paths() doesn't
bother to create a partial path for foo at all, because it's so small,
so hash_inner_and_outer() can't even consider a parallel join (that
needs partial paths on both sides).  What we want here is a shared
hash table so we can have shared match flags, an entirely new concern,
but create_plain_partial_path() can't see any point in a partial scan
of such a small table.  It works if you're OK creating partial paths
for everything...

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



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: pg_upgrade and logical replication
Next
From: Tom Lane
Date:
Subject: Re: Using each rel as both outer and inner for JOIN_ANTI