Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop() - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Date
Msg-id CAMbWs4_VNQNV-vSKWKDC7J-ts1qqy_TfZ3wJyA-bzS_d_ioxjw@mail.gmail.com
Whole thread Raw
In response to Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()  (Alexander Lakhin <exclusion@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: documentation structure
Next
From: Thomas Munro
Date:
Subject: Re: Windows default locale vs initdb