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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers