Re: bad plan

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: bad plan
Дата
Msg-id 4F7D65340200002500046BE4@gw.wicourts.gov
обсуждение исходный текст
Ответ на bad plan  (Julien Cigar <jcigar@ulb.ac.be>)
Список pgsql-performance
Julien Cigar <jcigar@ulb.ac.be> wrote:

> I tried to play on the various cost settings but it's doesn't
> change anything, except setting random_page_cost to 1 (which will
> lead to bad plans for other queries, so not a solution)

Yeah, you clearly don't have the active portion of your database
fully cached, so you don't want random_page_cost to go as low as
seq_page_cost.

Here's one suggestion to try:

random_page_cost = 2
cpu_tuple_cost = 0.05

I have found that combination to work well for me when the level of
caching is about where you're seeing it.  I am becoming increasingly
of the opinion that the default for cpu_tuple_cost should be higher
than 0.01.

Please let us know whether that helps.

-Kevin

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

Предыдущее
От: Marcos Ortiz
Дата:
Сообщение: Re: postgresql.conf setting for max_fsm_pages
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: postgresql.conf setting for max_fsm_pages