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
> 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.
> 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
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: