On 2014-05-06 15:09:15 +0100, Simon Riggs wrote:
> On 8 October 2013 17:13, Bruce Momjian <bruce@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