Heikki Linnakangas <heikki@enterprisedb.com> 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
