Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date
Msg-id 50ECCA9C.5070302@dunslane.net
Whole thread Raw
In response to Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
List pgsql-hackers
On 01/08/2013 08:08 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> ...  And I don't especially like the idea of trying to
>>> make it depend directly on the box's physical RAM, for the same
>>> practical reasons Robert mentioned.
>> For the record, I don't believe those problems would be particularly
>> hard to solve.
> 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.
>
> I'd prefer to go with a default that's predictable and not totally
> foolish --- and some multiple of shared_buffers seems like it'd fit the
> bill.

+1. That seems to be by far the biggest bang for the buck. Anything else 
will surely involve a lot more code for not much more benefit.

cheers

andrew



pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: pg_dump transaction's read-only mode
Next
From: Josh Berkus
Date:
Subject: PL/perl should fail on configure, not make