Re: Postgres picks suboptimal index after building of an extended statistics

Поиск
Список
Период
Сортировка
От Andrey Lepikhov
Тема Re: Postgres picks suboptimal index after building of an extended statistics
Дата
Msg-id 2df148b5-0bb8-f80b-ac03-251682fab585@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Postgres picks suboptimal index after building of an extended statistics  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Postgres picks suboptimal index after building of an extended statistics  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 7/8/22 03:07, Tom Lane wrote:
> Andrey Lepikhov <a.lepikhov@postgrespro.ru> writes:
>> On 12/8/21 04:26, Tomas Vondra wrote:
>>> 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.
> 
> I looked at this briefly.  I do not think that messing with
> btcostestimate/genericcostestimate is the right response at all.
> The problem can be demonstrated with no index whatever, as in the
> attached shortened version of the original example.  I get

I partly agree with you. Yes, I see the problem too. But also we have a 
problem that I described above: optimizer don't choose a path with 
minimal selectivity from a set selectivities which shows cardinality 
less than 1 (see badestimate2.sql).
New patch (see in attachment), fixes this problem.

-- 
Regards
Andrey Lepikhov
Postgres Professional
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: AIX support - alignment issues
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Reducing Memory Consumption (aset and generation)