Re: Redesigning checkpoint_segments - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Redesigning checkpoint_segments
Date
Msg-id CA+TgmoZyfMyawtoYnzDWPvgoWWu5xijU9BNRj76o3rfW5DPN7Q@mail.gmail.com
Whole thread Raw
In response to Re: Redesigning checkpoint_segments  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Redesigning checkpoint_segments  (David Steele <david@pgmasters.net>)
List pgsql-hackers
On Wed, Feb 4, 2015 at 1:05 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Let me push "max_wal_size" and "min_wal_size" again as our new parameter
> names, because:
>
> * does what it says on the tin
> * new user friendly
> * encourages people to express it in MB, not segments
> * very different from the old name, so people will know it works differently

That's not bad.  If we added a hard WAL limit in a future release, how
would that fit into this naming scheme?

>> We are too often far too conservative about these things.  If we make
>> the default 192MB, it will only ever get tuned in one direction: up.
>> It is not a bad thing for us to set the settings high enough that once
>> in a great while someone might find them to be too high rather than
>> too low.
>>
>> I find it amazing that anyone here thinks that a user would be OK with
>> using 192MB of space for WAL, but 384MB would break the bank.  The
>> hard drive in my laptop is 456GB.  The point is, with Heikki's work
>> here, you're only going to use the maximum amount of space if you have
>> massive write activity.  And if you have massive write activity, it's
>> extremely likely that you will be OK with using a very modest amount
>> of disk space to have that be fast.  Right now, we have to be really
>> conservative because we're going to use the full allocation all the
>> time, but this fixes that.  I think.
>
> Hmmm, I see your point.  I spend a lot of time on AWS and in
> container-world, where disk space is a lot more constrained.  However,
> it probably makes more sense to recommend non-default settings for that
> environment, since it requires non-default settings anyway.
>
> So, 384MB?

That's certainly better, but I think we should go further.  Again,
you're not committed to using this space all the time, and if you are
using it you must have a lot of write activity, which means you are
not running on a tin can and a string.  If you have a little tiny
database, say 100MB, running on a little-tiny Amazon instance,
handling a small number of transactions, you're going to stay close to
wal_min_size anyway.  Right?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: binworld and install-binworld targets - was Re: Release note bloat is getting out of hand
Next
From: Magnus Hagander
Date:
Subject: Re: File based Incremental backup v9