Re: shared_buffers documentation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: shared_buffers documentation
Date: 2010-04-20 01:28:09
Message-ID: p2h603c8f071004191828z3a096d1etc512deb000d32921@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 19, 2010 at 9:23 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> > Well, the point is that you are getting it for _unusual_ circumstances.
>> > Seems it is only when you are getting it for typical workloads that it
>> > should be increased.
>>
>> I guess.  I am not sure we should consider "doing a large CTAS" to be
>> an unusual workload, though.  Sure, most of us don't do that every
>> day, but what do we get out of having it be slow when we do decide to
>> do it?  Up until today, I had never heard anyone say that there was
>> any possible performance trade-off, and...
>>
>> > However, this is the first time I am hearing that
>> > battery-backed cache favors the default value.
>>
>> ...if that's as bad as it gets, I'm still not sure we shouldn't
>> increase the default.  Most people will not have their first
>> experience of PG on a server with a battery-backed RAID controller,
>> I'm thinking.  And people who do have battery-backed RAID controllers
>> can tune the value down if need be.  I have never yet heard anyone
>> justify why all the values in postgresql.conf should be defined as
>> "the lowest value that works best for at least 1 user".
>>
>> Then again, I don't really know what I'm talking about.  I think we
>> should be listening very carefully to people who have spent a lot of
>> time tuning this and taking their advice on how it should be set by
>> default.
>
> The current default was just chosen to reduce the PG disk footprint.  It
> probably should be increased, unless we find that the smaller working
> set is a win in many cases.

Yeah. 48MB is not much these days.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-04-20 01:51:16 Re: plpgsql GUC variable: custom or built-in?
Previous Message Bruce Momjian 2010-04-20 01:25:20 Re: pgindent and tabs in comments