Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Дата
Msg-id CA+U5nMLJBS-XxG6Gc1djHLA26hg7K7Fhp8CGb6Am_Zo1FquB2w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On 6 May 2014 20:41, Jeff Janes <jeff.janes@gmail.com> wrote:

> The e_c_s is assumed to be usable for each backend trying to run queries
> sensitive to it.  If you have dozens of such queries running simultaneously
> (not something I personally witness, but also not insane) and each of these
> queries has its own peculiar working set, then having e_c_s smaller than s_b
> makes sense.
>
> I have a hard time believe that this is at all common, however.

If larger queries are frequent enough to care about, they will happen together.

We should be acting conservatively with default settings. You can be
as aggressive as you like with your own config.

> Certainly
> not common enough so to justify cranking the setting all the way the other
> direction and then removing the crank handle.

Yes, that part was mostly rhetorical, I wasn't arguing for complete
removal, especially when autotuning is unclear.

I am worried about people that set effective_cache_size but not
shared_buffers, which is too common. If we link the two parameters it
should work in both directions by default.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Sending out a request for more buildfarm animals?