On Fri, 2007-06-22 at 16:21 -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
> > 3. Recovery will take longer, because the distance last committed redo
> > ptr will lag behind more.
>
> True, you'd have to replay 1.5 checkpoint intervals on average instead
> of 0.5 (more or less, assuming checkpoints had been short). I don't
> think we're in the business of optimizing crash recovery time though.
Agreed, though only for crash recovery. Most archive recoveries will not
be change noticeably - half a checkpoint isn't very long in PITR terms.
> It might be that getting rid of checkpoint_smoothing is an overreaction,
> and that we should keep that parameter. IIRC Greg had worried about
> being able to turn this behavior off, so we'd still need at least a
> bool, and we might as well expose the fraction instead. (Still don't
> like the name "smoothing" though.)
ISTM we don't need the checkpoint_smoothing parameter.
I can't see why anyone would want to turn off smoothing: If they are
doing many writes, then they will be effected by the sharp dive at
checkpoint, which happens *every* checkpoint. The increase in crash
recovery time is an easily acceptable trade-off for what is gained; if
not, they can always make checkpoint_timeout smaller.
If they aren't doing many writes they don't care what the setting of
checkpoint_smoothing is and recovery will be very fast anyway.
>I agree with removing the non-LRU
> part of the bgwriter's write logic though; that should simplify matters
> a bit and cut down the overall I/O volume.
Yes, agreed.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
