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

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Using each rel as both outer and inner for JOIN_ANTI
Дата
Msg-id CA+hUKG+cQroWxxt-8-fGNBPotABQbHG4aD9vNZ5hhyyF_cH-4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Using each rel as both outer and inner for JOIN_ANTI  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Using each rel as both outer and inner for JOIN_ANTI
Список 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 по дате отправления:

Предыдущее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: pg_upgrade and logical replication
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Using each rel as both outer and inner for JOIN_ANTI