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-05-05T11:38:39Z
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/29/25 19:25, Alexander Pyhalov wrote:
> Andrei Lepikhov писал(а) 2025-04-29 16:52:
> But it seems, base_path can't be NULL
Correct. Fixed.

> 
> Also we check base_path for required_outer and require_parallel_safe, 
> but if cheapest path for pathkeys is NULL, these checks are not 
> performed. 
Thanks. Fixed.

 > Luckily, they seen to be no-op anyway due to cheapest_total- > 
 >param_info == NULL and function arguments being NULL (required_outer)
> and false (require_parallel_safe). Should we do something about this? 
> Don't know, perhaps, remove these misleading arguments?
The main reason why I introduced these _ext routines was that this 
schema may be used somewhere else. And in that case parameterised paths 
may exist. Who knows, may be parameterised paths will be introduced for 
merge append too?

> become no-op? And we do return non-null path from 
> get_cheapest_fractional_path_for_pathkeys_ext(), as it seems we return 
> either cheapest_total_path or cheapest fractional path from 
> get_cheapest_fractional_path_for_pathkeys_ext().
Ok.

Let's check next version of the patch in the attachment.

-- 
regards, Andrei Lepikhov