Re: MergeAppend could consider sorting cheapest child path - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: MergeAppend could consider sorting cheapest child path
Date
Msg-id ebb22581-e4c5-4ea3-90ac-dbbcb3020529@gmail.com
Whole thread Raw
In response to Re: MergeAppend could consider sorting cheapest child path  (Alexander Pyhalov <a.pyhalov@postgrespro.ru>)
Responses Re: MergeAppend could consider sorting cheapest child path
Re: MergeAppend could consider sorting cheapest child path
List pgsql-hackers
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
Attachment

pgsql-hackers by date:

Previous
From: Yura Sokolov
Date:
Subject: Re: Fix a race condition in ConditionVariableTimedSleep()
Next
From: Andrei Lepikhov
Date:
Subject: Re: MergeAppend could consider sorting cheapest child path