Re: Redesigning checkpoint_segments

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Venkata Balaji N <nag1010(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Redesigning checkpoint_segments
Date: 2015-02-04 20:06:49
Message-ID: CA+TgmoZyfMyawtoYnzDWPvgoWWu5xijU9BNRj76o3rfW5DPN7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 4, 2015 at 1:05 PM, Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2015-02-04 20:12:29 Re: File based Incremental backup v9
Previous Message Andrew Dunstan 2015-02-04 19:24:14 binworld and install-binworld targets - was Re: Release note bloat is getting out of hand