Re: Postgres picks suboptimal index after building of an extended statistics - Mailing list pgsql-hackers

From Andrey V. Lepikhov
Subject Re: Postgres picks suboptimal index after building of an extended statistics
Date
Msg-id 90a1d6ef-c777-b95d-9f77-0065ad4522df@postgrespro.ru
Whole thread Raw
In response to Re: Postgres picks suboptimal index after building of an extended statistics  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On 8/12/21 4:26 AM, Tomas Vondra wrote:
> On 8/11/21 2:48 AM, Peter Geoghegan wrote:
>> On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
>> <a.lepikhov@postgrespro.ru> wrote:
>>> Ivan Frolkov reported a problem with choosing a non-optimal index during
>>> a query optimization. This problem appeared after building of an
>>> extended statistics.
>>
>> Any thoughts on this, Tomas?
>>
> 
> Thanks for reminding me, I missed / forgot about this thread.
> 
> I agree the current behavior is unfortunate, but I'm not convinced the 
> proposed patch is fixing the right place - doesn't this mean the index 
> costing won't match the row estimates displayed by EXPLAIN?
I think, it is not a problem. In EXPLAIN you will see only 1 row 
with/without this patch.
> 
> I wonder if we should teach clauselist_selectivity about UNIQUE indexes, 
> and improve the cardinality estimates directly, not just costing for 
> index scans.
This idea looks better. I will try to implement it.
> 
> Also, is it correct that the patch calculates num_sa_scans only when 
> (numIndexTuples >= 0.0)?
Thanks, fixed.

-- 
regards,
Andrey Lepikhov
Postgres Professional

Attachment

pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
Next
From: Gavin Flower
Date:
Subject: Re: Default to TIMESTAMP WITH TIME ZONE?