Re: MergeAppend could consider sorting cheapest child path
От | Andrei Lepikhov |
---|---|
Тема | Re: MergeAppend could consider sorting cheapest child path |
Дата | |
Msg-id | 8a2d4848-0574-4f42-a50d-a37c238d1f22@gmail.com обсуждение исходный текст |
Ответ на | Re: MergeAppend could consider sorting cheapest child path (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: MergeAppend could consider sorting cheapest child path
|
Список | pgsql-hackers |
On 1/9/2025 22:26, Alexander Korotkov wrote: > On Thu, Jul 31, 2025 at 5:20 PM Andrei Lepikhov <lepihov@gmail.com> wrote: >> See this minor correction in the attachment. postgres_fdw tests are >> stable now. > > I have another idea. What if we allow MergeAppend paths only when at > least one subpath is preordered. This trick also allow us to exclude > MergeAppend(Sort) dominating Sort(Append). I see the regression tests > changes now have much less volume and looks more reasonable. What do > you think? I believe a slight mistake has been made with the total_has_ordered / startup_has_ordered parameters, which has caused unnecessary test changes in inherit.out (See updated patch in the attachment). Although not the best test in general (it depends on the autovacuum), it highlighted the case where a startup-optimal strategy is necessary, even when a fractional-optimal path is available, which may lead to continue of the discussion [1].> > Also, do you think get_cheapest_fractional_path_for_pathkeys_ext() and > get_cheapest_path_for_pathkeys_ext() should consider incremental sort? > The revised patch teaches them to do so. Following 55a780e9476 [2] it should be considered, of course. [1] https://www.postgresql.org/message-id/CAPpHfduicoMCJ0b0mMvMQ5KVqLimJ7pKdxajciSF%2BP7JF31v%2BA%40mail.gmail.com [2] https://www.postgresql.org/message-id/CAMbWs49wSNPPD%3DFOQqzjPNZ_N9EGDv%3D7-ou0dFgd0HSwP3fTAg%40mail.gmail.com?utm_source=chatgpt.com -- regards, Andrei Lepikhov
Вложения
В списке pgsql-hackers по дате отправления: