Hello Richard,
18.07.2024 17:30, Richard Guo wrote:
The problemed plan is a non-parallel nestloop join. It's just chance
which join order the planner will pick, and slight variations in
underlying statistics could result in a different displayed plan.
From the two verbose plans, we can see slight variations in the
statistics for the parallel seqscan of tenk1.
-> Parallel Seq Scan on public.tenk1 t1 (cost=0.00..370.00 rows=2500
width=244)
VS.
-> Parallel Seq Scan on public.tenk1 t1 (cost=0.00..369.99 rows=2499
width=244)
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;").
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!
[1]
https://www.postgresql.org/message-id/flat/66eb9a6e-fc67-a230-c5b1-2a741e8b88c6%40gmail.com
Best regards,
Alexander
