Horton

Re: MergeAppend could consider sorting cheapest child path

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Alexander Pyhalov <a.pyhalov@postgrespro.ru>
Cc: Andy Fan <zhihuifan1213@163.com>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Alexander Korotkov <aekorotkov@gmail.com>, Nikita Malakhov <HukuToc@gmail.com>
Date: 2025-04-29T13:52:40Z
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

Attachments

On 4/25/25 17:13, Andrei Lepikhov wrote:
> On 4/25/25 11:16, Alexander Pyhalov wrote:
>> Usually, sorted cheapest_total_path will be cheaper than sorted 
>> fractional/startup path at least by startup cost (as after sorting it 
>> includes total_cost of input path). But we ignore this case when 
>> selecting cheapest_startup and cheapest_fractional subpaths. As result 
>> selected cheapest_startup and cheapest_fractional can be not cheapest 
>> for startup or selecting a fraction of rows.
> I don't know what you mean by that. The cheapest_total_path is 
> considered when we chose optimal cheapest_total path. The same works for 
> the fractional path - get_cheapest_fractional_path gives us the most 
> optimal fractional path and probes cheapest_total_path too.
> As above, not sure about min-startup case for now. I can imagine 
> MergeAppend over sophisticated subquery: non-sorted includes highly 
> parameterised JOINs and the alternative (with pathkeys) includes 
> HashJoin, drastically increasing startup cost. It is only a theory, of 
> course. So, lets discover how min-startup works.
After a second thought I have caught your idea. I agree that for a 
fractional path it have no sense to choose any other path except a 
cheapest total one.
There are the modified patch in the attachment.

Also, to be more objective, I propose to use examples in argumentation - 
something like in attached test2.sql script.

-- 
regards, Andrei Lepikhov