LGTM. I just have a few small wording suggestions.
+ completion overhead. Reducing this parameter is not recommended as that
+ causes the I/O from the checkpoint to have to complete faster, resulting
+ in a higher I/O rate, while then having a period of less I/O between the
+ completion of the checkpoint and the start of the next scheduled
+ checkpoint. This parameter can only be set in the
Reducing this parameter is not recommended because it forces the
checkpoint to complete faster. This results in a higher rate of I/O
during the checkpoint followed by a period of less I/O between
checkpoint completion and the next scheduled checkpoint.
+ duration). This spreads out the I/O as much as possible to have the I/O load be
+ consistent during the checkpoint. The disadvantage of this is that prolonging
This spreads out the I/O as much as possible so that the checkpoint
I/O load is consistent throughout the checkpoint interval.
+ around for possible use in recovery. A user concerned about the amount of time
+ required to recover might wish to reduce <varname>checkpoint_timeout</varname>,
+ causing checkpoints to happen more frequently while still spreading out the I/O
+ from each checkpoint. Alternatively,
A user concerned about the amount of time required to recover might
wish to reduce checkpoint_timeout so that checkpoints occur more
frequently but still spread the I/O across the checkpoint interval.
+ Although <varname>checkpoint_completion_target</varname> could be set as high as
+ 1.0, it is best to keep it less than that (such as at the default of 0.9, at most)
+ since checkpoints include some other activities besides writing dirty buffers.
Although checkpoint_completion_target can be set as high at 1.0, it is
typically recommended to set it to no higher than 0.9 (the default)
since checkpoints include some other activities besides writing dirty
buffers.
Nathan