On Fri, 2007-06-22 at 16:21 -0400, Tom Lane wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate