Re: MergeAppend could consider sorting cheapest child path

On Fri, Sep 5, 2025 at 11:45 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>
> On 1/9/2025 22:26, Alexander Korotkov wrote:
> > On Thu, Jul 31, 2025 at 5:20 PM Andrei Lepikhov <lepihov(at)gmail(dot)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.

Great, thank you for catching this. The diff of costs is attached. I
see the costs now are better or within the fuzz factor.

------
Regards,
Alexander Korotkov
Supabase