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 по дате отправления: