Re: Incremental Sort Cost Estimation Instability - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Incremental Sort Cost Estimation Instability
Date
Msg-id 02d41b2c-fe56-4be9-b7b0-8f96dfb91375@gmail.com
Whole thread Raw
In response to Re: Incremental Sort Cost Estimation Instability  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers
On 12/9/2024 16:57, Tomas Vondra wrote:
> On 9/12/24 12:12, David Rowley wrote:
>> On Thu, 12 Sept 2024 at 21:51, Andrei Lepikhov <lepihov@gmail.com> wrote:
> I'm not sure how to fix this, but it seems estimate_num_groups() needs
> to do things differently. And I agree looking for the minimum ndistinct
> seems like the right approach. but doesn't estimate_num_groups()
> supposed to already do that? The comment says:
I've rewritten the code in the previous email. It looks like we can try 
to rewrite estimate_num_groups to do it more effectively, but I haven't 
done it yet.
Regarding the tiny change in the cost, my initial reason was to teach 
cost_sort to differ sort orderings: begin by considering the number of 
columns in the cost estimation and then consider the distinct estimation 
of the first column.
BTW, it was triggered by user reports, where a slight change in the 
balance between MergeAppend/GatherMerge/Sort/IncrementalSort (or columns 
order) could give significant profit. Especially when grouping millions 
of rows in 2-4 bytea columns.

-- 
regards, Andrei Lepikhov




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: miscellaneous pg_upgrade cleanup
Next
From: Tomas Vondra
Date:
Subject: Re: Why don't we consider explicit Incremental Sort?