On 2014-05-06 15:09:15 +0100, Simon Riggs wrote: > On 8 October 2013 17:13, Bruce Momjian <br...@momjian.us> wrote: > > > Patch applied with a default of 4x shared buffers. I have added a 9.4 > > TODO that we might want to revisit this. > > I certainly want to revisit this patch and this setting. > > How can we possibly justify a default setting that could be more than > physical RAM?
Because it doesn't hurt overly much if it's set too large? > The maximum known safe value is the setting of shared_buffers itself, > without external knowledge. But how can we possibly set it even that > high? > > Does anyone have any evidence at all on how to set this? How can we > possibly autotune it? It's just a different default setting? I think the new value will cause less problems than the old one which frequently leads to index scans not being used although beneficial. > I prefer the idea of removing "effective_cache_size" completely, since > it has so little effect on workloads and is very frequently > misunderstood by users. It's just dangerous, without being useful. -many. > Lets fix e_c_s at 25% of shared_buffers and remove the parameter > completely, just as we do with so many other performance parameters. That'd cause *massive* regression for many installations. Without significantly overhauling costsize.c that's really not feasible. There's lots of installations that use relatively small s_b settings for good reasons. If we fix e_c_s to 25% of s_b many queries on those won't use indexes anymore. 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