Horton

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

Richard Guo <guofenglinux@gmail.com>

View thread View on postgr.es
From: Richard Guo <guofenglinux@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>, Tomasz Rybak <tomasz.rybak@post.pl>, pgsql-hackers@lists.postgresql.org, robertmhaas@gmail.com, David Rowley <dgrowleyml@gmail.com>, "Fujii.Yuki@df.MitsubishiElectric.co.jp" <Fujii.Yuki@df.mitsubishielectric.co.jp>
Date: 2024-07-18T08:11:50Z
Lists: pgsql-hackers 
On Thu, Jul 18, 2024 at 4:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
> Please look at a recent buildfarm failure [1], which shows some
> instability of that test addition:
>   -- the joinrel is not parallel-safe due to the OFFSET clause in the subquery
>   explain (costs off)
>       select * from tenk1 t1, (select * from tenk2 t2 offset 0) t2 where t1.two > t2.two;
> -                QUERY PLAN
> --------------------------------------------
> +                   QUERY PLAN
> +-------------------------------------------------
>    Nested Loop
>      Join Filter: (t1.two > t2.two)
> -   ->  Gather
> -         Workers Planned: 4
> -         ->  Parallel Seq Scan on tenk1 t1
> +   ->  Seq Scan on tenk2 t2
>      ->  Materialize
> -         ->  Seq Scan on tenk2 t2
> +         ->  Gather
> +               Workers Planned: 4
> +               ->  Parallel Seq Scan on tenk1 t1
>   (7 rows)

Thank you for the report and investigation.  Will have a look.

Thanks
Richard

Commits

  1. Fix unstable test in select_parallel.sql

  2. Consider materializing the cheapest inner path in parallel nestloop

  3. doc PG 17 relnotes: adjust IN wording

  4. Support parallel joins, and make related improvements.