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