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

From Jeff Janes
Subject Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date
Msg-id CAMkU=1wqP7h=Dp4tL5HSKAe9Jihn9RhgM6sVvevGekmGOgkqXQ@mail.gmail.com
Whole thread Raw
In response to Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Wed, May 7, 2014 at 11:04 AM, Josh Berkus <josh@agliodbs.com> wrote:
On 05/06/2014 10:35 PM, Peter Geoghegan wrote:
> +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.

Unfortunately nobody has the time/resources to do the kind of testing
required for a new recommendation for shared_buffers.

I think it is worse than that.  I don't think we know what such testing would even look like.  SSD?  BBU? max_connections=20000 with 256 cores?  pgbench -N?  capture and replay of Amazon's workload?

If we could spell out/agree upon what kind of testing we would find convincing, that would probably go a long way to getting some people to work on carrying out the tests.  Unless the conclusion was "please have 3TB or RAM and a 50 disk RAID", then there might be few takers.
 
Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: bgworker crashed or not?
Next
From: Tom Lane
Date:
Subject: jsonb existence queries are misimplemented by jsonb_ops