Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Ok, if we approach this from the idea that there will be *no* GUC > variables at all to control this, and we remove the bgwriter_all_* > settings as well, does anyone see a reason why that would be bad? Here's > the ones mentioned this far:
> 1. we need to keep 2x as much WAL segments around as before. No, only 50% more. We've always kept WAL back to the checkpoint-before-last, so the peak usage has been about 2 checkpoint distances (plus a bit), and now it'd tend to be about 3. > 2. pg_start_backup will need to wait for a long time. > 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. 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.) 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend