Re: Incremental Sort Cost Estimation Instability

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, tomas(at)vondra(dot)me
Subject: Re: Incremental Sort Cost Estimation Instability
Date: 2024-10-08 04:33:36
Message-ID: 6e23a2c8-1f41-4d9a-bcaa-ab3f1272e082@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/23/24 20:02, Andrei Lepikhov wrote:
> On 12/9/2024 12:12, David Rowley wrote:
>> On Thu, 12 Sept 2024 at 21:51, Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>>> Initial problem causes wrong cost_sort estimation. Right now I think
>>> about providing cost_sort() the sort clauses instead of (or in addition
>>> to) the pathkeys.
>>
>> I'm not quite sure why the sort clauses matter any more than the
>> EquivalenceClass.  If the EquivalanceClass defines that all members
>> will have the same value for any given row, then, if we had to choose
>> any single member to drive the n_distinct estimate from, isn't the
>> most accurate distinct estimate from the member with the smallest
>> n_distinct estimate?  (That assumes the less distinct member has every
>> value the more distinct member has, which might not be true)
> Finally, I implemented this approach in code (see attachment).
> The effectiveness may be debatable, but general approach looks even
> better than previous one.
> Change status to 'Need review'.
Minor change to make compiler and cfbot happy.

--
regards, Andrei Lepikhov

Attachment Content-Type Size
v3-0001-Stabilize-incremental-sort-estimation.patch text/x-patch 4.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-10-08 04:46:23 Re: per backend I/O statistics
Previous Message Andrei Lepikhov 2024-10-08 04:24:01 Re: Consider the number of columns in the sort cost model