Re: MergeAppend could consider sorting cheapest child path

Andy Fan писал(а) 2024-10-17 03:33:
> Bruce Momjian <bruce(at)momjian(dot)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