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

From Andrei Lepikhov
Subject Re: Incremental Sort Cost Estimation Instability
Date
Msg-id 188787ad-4847-4360-b4c1-b3ef136ea029@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:
>  but doesn't estimate_num_groups()
> supposed to already do that? The comment says:
> 
>   * 3.  If the list contains Vars of different relations that are known equal
>   * due to equivalence classes, then drop all but one of the Vars from each
>   * known-equal set, keeping the one with smallest estimated # of values
>   * (since the extra values of the others can't appear in joined rows).
>   * Note the reason we only consider Vars of different relations is that
>   * if we considered ones of the same rel, we'd be double-counting the
>   * restriction selectivity of the equality in the next step.
> 
> I haven't debugged this, but how come this doesn't do the trick?
I've got your point now.
Unfortunately, this comment says that estimate_num_groups removes 
duplicates from the list of grouping expressions (see 
exprs_known_equal). But it doesn't discover em_members to find the 
most-fitted clause for each grouping position.

-- 
regards, Andrei Lepikhov




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: scalability bottlenecks with (many) partitions (and more)
Next
From: Vladlen Popolitov
Date:
Subject: Re: Increase of maintenance_work_mem limit in 64-bit Windows