Re: MergeAppend could consider sorting cheapest child path

On 4/6/2025 00:41, Alexander Korotkov wrote:
> 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.
As I see it, it makes sense to charge MergeAppend for the heap operation
or, what is more logical, reduce the charge on Sort due to internal
optimisations.
Playing with both approaches, I found that it breaks many more tests
than the current patch does. Hence, it needs additional work on the
results analysis to realise how correct these changes are.

--
regards, Andrei Lepikhov