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

From Andrey Lepikhov
Subject Re: Postgres picks suboptimal index after building of an extended statistics
Date
Msg-id a5a18d86-c0e5-0ceb-9a18-be1beb2d2944@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>)
Responses Re: Postgres picks suboptimal index after building of an extended statistics  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 12/8/21 04:26, 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
> 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 rewrote the patch. It's now simpler and shorter. May be more convenient.
Also, it includes a regression test to detect the problem in future.
> 
> I wonder if we should teach clauselist_selectivity about UNIQUE indexes, 
> and improve the cardinality estimates directly, not just costing for 
> index scans.
I tried to implement this in different ways. But it causes additional 
overhead and code complexity - analyzing a list of indexes and match 
clauses of each index with input clauses in each selectivity estimation.
I don't like that way and propose a new patch in attachment.

-- 
regards,
Andrey Lepikhov
Postgres Professional

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Separate out FileSet from SharedFileSet (was Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o)
Next
From: Peter Eisentraut
Date:
Subject: Re: list of acknowledgments for PG14