Re: Incremental Sort Cost Estimation Instability

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Tomas Vondra <tomas(at)vondra(dot)me>, David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Subject: Re: Incremental Sort Cost Estimation Instability
Date: 2024-09-23 14:45:25
Message-ID: 188787ad-4847-4360-b4c1-b3ef136ea029@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladlen Popolitov 2024-09-23 14:47:52 Re: Increase of maintenance_work_mem limit in 64-bit Windows
Previous Message Tom Lane 2024-09-23 14:37:16 Re: scalability bottlenecks with (many) partitions (and more)