On 2013-09-11 12:53:29 -0400, Bruce Momjian wrote: > On Wed, Sep 11, 2013 at 12:43:07PM -0300, Alvaro Herrera wrote: > > Bruce Momjian escribió: > > > > > > So, are you saying you like 4x now? > > > > > > Here is an arugment for 3x. First, using the documented 25% of RAM, 3x > > > puts our effective_cache_size as 75% of RAM, giving us no room for > > > kernel, backend memory, and work_mem usage. If anything it should be > > > lower than 3x, not higher. > > > > The other argument I see for the 3x value is that it is a compromise. > > People with really large servers will want to increase it; people with > > very small servers will want to reduce it. > > Yes, you could make the argument that 2x is the right default, > especially considering work_mem.
I think that most of the arguments in this thread drastically overestimate the precision and the effect of effective_cache_size. The planner logic behind it basically only uses it to calculate things within a single index scan. That alone shows that any precise calculation cannot be very meaningful. It also does *NOT* directly influence how the kernel caches disk io. It's there to guess how likely it is something is still cached when accessing things repeatedly. I think nearly all practical experience shows that setting it smaller is more likely to cause problems than setting it too low. We shouldn't be too skimpy here. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers