Re: Redesigning checkpoint_segments

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Redesigning checkpoint_segments
Date: 2014-01-31 23:38:29
Message-ID: 20140131233829.GD19957@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 24, 2013 at 12:08:30AM +0300, Heikki Linnakangas wrote:
> You can also set min_recycle_wal_size = checkpoint_wal_size, which
> gets you the same behavior as without the patch, except that it's
> more intuitive to set it in terms of "MB of WAL space required",
> instead of "# of segments between checkpoints".
>
> Does that make sense? I'd love to hear feedback on how people
> setting up production databases would like to tune these things. The
> reason for the auto-tuning between the min and max is to be able to
> set reasonable defaults e.g for embedded systems that don't have a
> DBA to do tuning. Currently, it's very difficult to come up with a
> reasonable default value for checkpoint_segments which would work
> well for a wide range of systems. The PostgreSQL default of 3 is way
> way too low for most systems. On the other hand, if you set it to,
> say, 20, that's a lot of wasted space for a small database that's
> not updated much. With this patch, you can set "max_wal_size=1GB"
> and if the database ends up actually only needing 100 MB of WAL, it
> will only use that much and not waste 900 MB for useless
> preallocated WAL files.

Where are we on this?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message MauMau 2014-02-01 00:32:34 [review] PostgreSQL Service on Windows does not start if data directory given is relative path
Previous Message Josh Berkus 2014-01-31 23:34:02 Re: Recovery inconsistencies, standby much larger than primary