Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers - Mailing list pgsql-hackers

From Andres Freund
Subject Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date
Msg-id 20140507183832.GL13397@awork2.anarazel.de
Whole thread Raw
In response to Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Peter Geoghegan <pg@heroku.com>)
Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On 2014-05-07 13:32:41 -0500, Merlin Moncure wrote:
> On Wed, May 7, 2014 at 1:13 PM, Peter Geoghegan <pg@heroku.com> wrote:
> > On Wed, May 7, 2014 at 11:04 AM, Josh Berkus <josh@agliodbs.com> wrote:
> >> Unfortunately nobody has the time/resources to do the kind of testing
> >> required for a new recommendation for shared_buffers.
> >
> > I meant to suggest that the buffer manager could be improved to the
> > point that the old advice becomes obsolete. Right now, it's much
> > harder to analyze shared_buffers than it should be, presumably because
> > of the problems with the buffer manager. I think that if we could
> > formulate better *actionable* advice around what we have right now,
> > that would have already happened.
> >
> > We ought to be realistic about the fact that the current
> > recommendations around sizing shared_buffers are nothing more than
> > folk wisdom. That's the best we have right now, but that seems quite
> > unsatisfactory to me.
> 
> I think the stock advice is worse then nothing because it is A. based
> on obsolete assumptions and B. doesn't indicate what the tradeoffs are
> or what kinds of symptoms adjusting the setting could alleviate.  The
> documentation should be reduced to things that are known, for example:
> 
> *) raising shared buffers does not 'give more memory to postgres for
> caching' -- it can only reduce it via double paging

That's absolutely not a necessary consequence. If pages are in s_b for a
while the OS will be perfectly happy to throw them away.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: making bgworkers without shmem access actually not have shmem access
Next
From: Josh Berkus
Date:
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers