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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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