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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date: 2013-09-10 01:29:07
Message-ID: 20130910012907.GF32173@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 5, 2013 at 09:02:27PM -0700, Josh Berkus wrote:
> On 09/05/2013 03:30 PM, Merlin Moncure wrote:
>
> >> Standard advice we've given in the past is 25% shared buffers, 75%
> >> effective_cache_size. Which would make EFS *3X* shared_buffers, not 4X.
> >> Maybe we're changing the conventional calculation, but I thought I'd
> >> point that out.
> >
> > This was debated upthread.
>
> Actually, no, it wasn't. Tom threw out a suggestion that we use 4X for
> historical reasons. That's all, there was no discussion.
>
> So, my point stands: our historical advice has been to set EFS to 75% of
> RAM. Maybe we're changing that advice, but if so, let's change it.
> Otherwise 3X makes more sense.

So, what do we want the effective_cache_size default to be? 3x or 4x?
We clearly state:

If you have a dedicated database server with 1GB or more of RAM,
a reasonable starting value for shared_buffers is 25% of the
memory in your system. There are some workloads where even

If we make the default 4x, that means that people using the above
suggestion would be setting their effective_cache_size to 100% of RAM?
If we go with 4x, which I believe was the majority opinion, what shall
we answer to someone who asks about this contradiction?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-09-10 01:54:44 Re: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Previous Message Peter Geoghegan 2013-09-10 01:27:56 Re: New statistics for WAL buffer dirty writes