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

From Alexander Pyhalov
Subject Re: MergeAppend could consider sorting cheapest child path
Date
Msg-id 242cc7689213c0e7fafc7cd1add79b4d@postgrespro.ru
Whole thread Raw
In response to Re: MergeAppend could consider sorting cheapest child path  (Andy Fan <zhihuifan1213@163.com>)
List pgsql-hackers
Andy Fan писал(а) 2024-10-17 03:33:
> Bruce Momjian <bruce@momjian.us> writes:
> 
>> Is this still being considered?
> 
> I'd +1 on this feature. I guess this would be more useful on parallel
> case, where the Sort can be pushed down to parallel worker, and in the
> distributed database case, where the Sort can be pushed down to 
> multiple
> nodes, at the result, the leader just do the merge works.
> 
> At the high level implementaion, sorting *cheapest* child path looks
> doesn't add too much overhead on the planning effort.

Hi.

I've updated patch. One more interesting case which we found - when 
fractional path is selected, it still can be more expensive than sorted 
cheapest total path (as we look only on indexes whith necessary 
pathkeys, not on indexes which allow efficiently fetch data).
So far couldn't find artificial example, but we've seen inadequate index 
selection due to this issue - instead of using index suited for filters 
in where, index, suitable for sorting was selected as one having the 
cheapest fractional cost.
-- 
Best regards,
Alexander Pyhalov,
Postgres Professional
Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Thread-safe nl_langinfo() and localeconv()
Next
From: Filip Janus
Date:
Subject: Re: Proposal: Adding compression of temporary files