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