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.


> 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.


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:

Reply via email to