Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

postgresql.conf.sample

Blame
    • Heikki Linnakangas's avatar
      88e98230
      Replace checkpoint_segments with min_wal_size and max_wal_size. · 88e98230
      Heikki Linnakangas authored
      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.
      88e98230
      History
      Replace checkpoint_segments with min_wal_size and max_wal_size.
      Heikki Linnakangas authored
      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.