On Thu, Sep 5, 2013 at 03:11:53PM -0700, Josh Berkus wrote:
> On 09/05/2013 02:16 PM, Bruce Momjian wrote:
> >> Well, the real problem with this patch is that it documents what the
> >> auto-tuning algorithm is; without that commitment, just saying "-1 means
> >> autotune" might be fine.
> >
> > OK, but I did this based on wal_buffers, which has a -1 default, calls
> > it auto-tuning, and explains how the default is computed.
>
> I don't see a real problem with this. For users who have set their
> shared_buffers correctly, effective_cache_size should also be correct.
>
> > The problem there is that many users are told to tune shared_buffers,
> > but don't touch effective cache size. Having initdb set the
> > effective_cache_size value would not help there. Again, this is all
> > based on the auto-tuning of wal_buffers.
>
> 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.
Yes, I had wondered that myself, and 3x and 4x were thrown out as
options. There were more people who liked 4x, but one of the reasons
was that 3x sounded odd --- not sure what to make of that, but I went
with the most popular. I am fine with 3x, and I do think it logically
makes more sense, and is less likely to over-estimate than 4x.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +