Re: Load Distributed Checkpoints, take 3

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