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

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Дата
Msg-id 5369CADC.9070409@catalyst.net.nz
обсуждение исходный текст
Ответ на Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 07/05/14 17:35, Peter Geoghegan wrote:
> On Tue, May 6, 2014 at 10:20 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 6 May 2014 23:47, Josh Berkus <josh@agliodbs.com> wrote:
>>
>>> If you're going to make
>>> an argument in favor of different tuning advice, then do it based on
>>> something in which you actually believe, based on hard evidence.
>> The proposed default setting of 4x shared_buffers is unprincipled
>> *and* lacks hard evidence from you and everybody else.
> +1. In my view, we probably should have set it to a much higher
> absolute default value. The main problem with setting it to any
> multiple of shared_buffers that I can see is that shared_buffers is a
> very poor proxy for what effective_cache_size is supposed to
> represent. In general, the folk wisdom around sizing shared_buffers
> has past its sell-by date.
>

+1. ISTM the only sensible approach to auto tune this requires us to 
have a plugin to detect how much RAM the system has (and then setting it 
to 1/2 that say). I wonder if it might be worthwhile writing plugins for 
the handful of popular platforms. For the remainder maybe we could leave 
it defaulting to the current (small) value, and encourage volunteers to 
code the missing ones if they want something better.

Regards

Mark



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [v9.5] Custom Plan API