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

Richard Guo <guofenglinux@gmail.com>

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-22T02:43:50Z
Lists: pgsql-hackers
On Fri, Jul 19, 2024 at 12:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
> 18.07.2024 17:30, Richard Guo wrote:
> > I have no idea why the underlying statistics changed, but it seems
> > that this slight change is sufficent to result in a different plan.
>
> I think it could be caused by the same reason as [1] and I really can
> easily (without multiple instances/loops. just with `make check`) reproduce
> the failure with cranky-ConditionalLockBufferForCleanup.patch (but
> targeted for "VACUUM ANALYZE tenk1;").

Yeah.  Anyway I think we need to make the test more tolerant of slight
variations in the statistics.

> > According to the discussion in [1], I think what we wanted to test
> > with this query is that parallel nestloop join is not generated if the
> > inner path is not parallel-safe.  Therefore, I modified this test case
> > to use a lateral join, rendering the inner path not parallel-safe
> > while also enforcing the join order.  Please see attached.
>
> The modified test survives my testing procedure. Thank you for the patch!

Thanks for testing this patch.  I've pushed it.

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.