|From:||Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>|
|To:||Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>, pgsql-committers(at)postgresql(dot)org|
|Subject:||Re: pgsql: Replace checkpoint_segments with min_wal_size and max_wal_size.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 02/23/2015 05:53 PM, Heikki Linnakangas wrote:
> Replace checkpoint_segments with min_wal_size and max_wal_size.
> Instead of having a single knob (checkpoint_segments) that both triggers
> checkpoints, and determines how many checkpoints to recycle, they are now
> separate concerns. There is still an internal variable called
> CheckpointSegments, which triggers checkpoints. But it no longer determines
> how many segments to recycle at a checkpoint. That is now auto-tuned by
> keeping a moving average of the distance between checkpoints (in bytes),
> and trying to keep that many segments in reserve. The advantage of this is
> that you can set max_wal_size very high, but the system won't actually
> consume that much space if there isn't any need for it. The min_wal_size
> sets a floor for that; you can effectively disable the auto-tuning behavior
> by setting min_wal_size equal to max_wal_size.
> The max_wal_size setting is now the actual target size of WAL at which a
> new checkpoint is triggered, instead of the distance between checkpoints.
> Previously, you could calculate the actual WAL usage with the formula
> "(2 + checkpoint_completion_target) * checkpoint_segments + 1". With this
> patch, you set the desired WAL usage with max_wal_size, and the system
> calculates the appropriate CheckpointSegments with the reverse of that
> formula. That's a lot more intuitive for administrators to set.
> Reviewed by Amit Kapila and Venkata Balaji N.
I think this one broke the docs build:
|Next Message||Peter Eisentraut||2015-02-23 21:58:22||pgsql: Fix invalid DocBook XML|
|Previous Message||Alvaro Herrera||2015-02-23 18:05:47||pgsql: Fix stupid merge errors in previous commit|