Horton

Re: MergeAppend could consider sorting cheapest child path

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Alexander Pyhalov <a.pyhalov@postgrespro.ru>, Andy Fan <zhihuifan1213@163.com>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Nikita Malakhov <HukuToc@gmail.com>
Date: 2025-06-03T14:35:57Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Mostly-cosmetic adjustments to estimate_multivariate_bucketsize().

  2. Consider fractional paths in generate_orderedappend_paths

On 3/6/2025 16:05, Alexander Korotkov wrote:
> On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov <lepihov@gmail.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.

-- 
regards, Andrei Lepikhov