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

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Дата
Msg-id CAMbWs4_VNQNV-vSKWKDC7J-ts1qqy_TfZ3wJyA-bzS_d_ioxjw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()  (Alexander Lakhin <exclusion@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: Re: documentation structure
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Windows default locale vs initdb