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

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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date: 2013-01-09 01:40:44
Message-ID: 50ECCA9C.5070302@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On 01/08/2013 08:08 PM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2013-01-09 01:48:17
Subject: PL/perl should fail on configure, not make
Previous:From: Gurjeet SinghDate: 2013-01-09 01:12:34
Subject: Re: pg_dump transaction's read-only mode

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