Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
| От | Jeff Janes |
|---|---|
| Тема | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
| Дата | |
| Msg-id | CAMkU=1yktwAOLCHic6jcOF5vTCtZ=V5JRpePonxhXCP32CMUQA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: proposal: Set effective_cache_size to greater of .conf
value, shared_buffers
|
| Список | pgsql-hackers |
On Wed, May 7, 2014 at 11:38 AM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2014-05-07 13:32:41 -0500, Merlin Moncure wrote:That's absolutely not a necessary consequence. If pages are in s_b for a
>
> *) raising shared buffers does not 'give more memory to postgres for
> caching' -- it can only reduce it via double paging
while the OS will be perfectly happy to throw them away.
Is that an empirical observation? I've run some simulations a couple years ago, and also wrote some instrumentation to test that theory under favorably engineered (but still plausible) conditions, and couldn't get more than a small fraction of s_b to be so tightly bound in that the kernel could forget about them. Unless of course the entire workload or close to it fits in s_b.
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: