Re: BUG #7619: Query cost estimate appears to not use n_distinct setting

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: BUG #7619: Query cost estimate appears to not use n_distinct setting
Дата
Msg-id 20121025015648.306900@gmx.com
обсуждение исходный текст
Список pgsql-bugs
Tom Lane wrote:

> plus some not-very-large CPU-per-tuple charges

In my experience, cpu_tuple_cost should be higher. I've often had to
boost it to get good plans for a wide mix of queries in a load.
Doubling it to 0.02 is often not enough to get good plans. I've taken
it to 0.05 with production workloads without ill effect, but
personally have not seen further improvements beyond the plans I got
at 0.03. Among other things, this setting tends to make the ratio
between random_page_cost and seq_page_cost somewhat less sensitive;
although I still find it best to take them both down to 0.1 for fully
cached workloads, along with the cpu_tuple_cost boost.

I think we should raise the default for cpu_tuple_cost, but have been
reluctant to suggest it based on just my personal experiences. Has
anyone else found this useful?

-Kevin

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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Introducing floating point cast into filter drastically changes row estimate
Следующее
От: Dmitrijs Ledkovs
Дата:
Сообщение: Fails to build from source with multiarched python3.3 on Debian-like systems