| From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie>, "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Postgres picks suboptimal index after building of an extended statistics |
| Date: | 2021-08-11 23:26:29 |
| Message-ID: | f8044836-5d61-a4e0-af82-5821a2a1f0a7@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 8/11/21 2:48 AM, Peter Geoghegan wrote:
> On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)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 wonder if we should teach clauselist_selectivity about UNIQUE indexes,
and improve the cardinality estimates directly, not just costing for
index scans.
Also, is it correct that the patch calculates num_sa_scans only when
(numIndexTuples >= 0.0)?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Flower | 2021-08-11 23:49:55 | Re: 2021-08-12 release announcement draft |
| Previous Message | David Rowley | 2021-08-11 23:25:10 | Re: 2021-08-12 release announcement draft |