Re: Duplicate WHERE condition changes performance and plan

Поиск
Список
Период
Сортировка
От Michael Lewis
Тема Re: Duplicate WHERE condition changes performance and plan
Дата
Msg-id CAHOFxGoN1LZoR5Mf-C_OMCDC=_kL1AqfosPgfLOnXUN2--ugNA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Duplicate WHERE condition changes performance and plan  ("singh400@gmail.com" <singh400@gmail.com>)
Список pgsql-performance
Why not vacuum analyze both tables to ensure stats are up to date? 

Have you customized default_statistics_target from 100? It may be that 250 would give you a more complete sample of the table without increasing the size of the stats tables too much such that planning time increases hugely.

Do you know if any of these columns are correlated? Custom stats with CREATE STATISTICS may help the planner make better decisions if so.

I usually hesitate to put any boolean field in an index. Do you need the proposal.has_been_anonymised false values only, if so you could add that to a WHERE condition on the index instead of including it as the leading column.

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

Предыдущее
От: Jean-Christophe Boggio
Дата:
Сообщение: Re: Recursive query slow on strange conditions
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Please help! Query jumps from 1s -> 4m