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
-
Fix unstable test in select_parallel.sql
- 7e187a7386cc 18.0 landed
-
Consider materializing the cheapest inner path in parallel nestloop
- 22d946b0f86f 18.0 landed
-
doc PG 17 relnotes: adjust IN wording
- 8fea1bd5411b 17.0 cited
-
Support parallel joins, and make related improvements.
- 45be99f8cd5d 9.6.0 cited