Re: anti-join chosen even when slower than old plan

Поиск
Список
Период
Сортировка
От Vitalii Tymchyshyn
Тема Re: anti-join chosen even when slower than old plan
Дата
Msg-id 4CDD1279.5090809@gmail.com
обсуждение исходный текст
Ответ на Re: anti-join chosen even when slower than old plan  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Ответы Re: anti-join chosen even when slower than old plan
Список pgsql-performance
I'd say there are two Qs here:

1) Modify costs based on information on how much of the table is in
cache. It would be great  if this can be done, but I'd prefer to have it
as admin knobs (because of plan stability). May be both admin and
automatic ways can be followed with some parallel (disableable) process
modify knobs on admin behalf. In this case different strategies to
automatically modify knobs can be applied.

2) Modify costs for part of table retrieval. Then you need to define
"part". Current ways are partitioning and partial indexes. Some similar
to partial index thing may be created, that has only "where" clause and
no data. But has statistics and knobs (and may be personal bufferspace
if they are introduced). I don't like to gather data about "last X
percents" or like, because it works only in clustering and it's hard for
optimizer to decide if it will be enough to scan only this percents for
given query.

Best regards, Vitalii Tymchyshyn

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

Предыдущее
От: Cédric Villemain
Дата:
Сообщение: Re: anti-join chosen even when slower than old plan
Следующее
От: Cédric Villemain
Дата:
Сообщение: Re: anti-join chosen even when slower than old plan