Skip site navigation (1) Skip section navigation (2)

Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers

From: Benedikt Grundmann <bgrundmann(at)janestreet(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date: 2013-01-09 08:38:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jan 9, 2013 at 2:01 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> All,
> >> Well, the problem of "find out the box's physical RAM" is doubtless
> >> solvable if we're willing to put enough sweat and tears into it, but
> >> I'm dubious that it's worth the trouble.  The harder part is how to know
> >> if the box is supposed to be dedicated to the database.  Bear in mind
> >> that the starting point of this debate was the idea that we're talking
> >> about an inexperienced DBA who doesn't know about any configuration knob
> >> we might provide for the purpose.
> For what it is worth even if it is a dedicated database box 75% might be
way too high. I remember investigating bad performance on our biggest
database server, that in the end turned out to be a too high setting of
effective_cache_size. From reading the code back then my rationale for it
being to high was that the code that makes use of the effective_cache_size
tries very hard to account for what the current query would do to the cache
but doesn't take into account how many queries (on separate datasets!) are
currently begin executed (and competing for the same cache).  On that box
we often have 100+ active connections and many looking at different big



In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2013-01-09 08:45:10
Subject: inconsistent behave of boolean based domains in XML functions
Previous:From: Amit KapilaDate: 2013-01-09 08:34:32
Subject: Re: Extra XLOG in Checkpoint for StandbySnapshot

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group