Re: MergeAppend could consider sorting cheapest child path

On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> On 3/6/2025 16:05, Alexander Korotkov wrote:
> > On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> >> Additionally, as I mentioned earlier, the primary reason for choosing
> >> MergeAppend in the regression test was a slight total cost difference
> >> that triggered the startup cost comparison.
> >> May you show the query and its explain, that is a subject of concern for
> >> you?
> >
> > My point is that difference in total cost is very small. For small
> > datasets it could be even within the fuzzy limit. However, in
> > practice difference in total time is as big as difference in startup
> > time. So, it would be good to make the total cost difference bigger.
> For me, it seems like a continuation of the 7d8ac98 discussion. We may
> charge a small fee for MergeAppend to adjust the balance, of course.
> However, I think this small change requires a series of benchmarks to
> determine how it affects the overall cost balance. Without examples it
> is hard to say how important this issue is and its worthiness to
> commence such work.

Yes, I think it's fair to charge the MergeAppend node. We currently
cost it similarly to Sort merge stage, but it's clearly more
expensive. It dealing on the executor level dealing with Slot's etc,
while Sort node have a set of lower level optimizations.

------
Regards,
Alexander Korotkov
Supabase