> (2) Remove bgwriter_percent. I have yet to hear anyone argue that
> there's an actual need for bgwriter_percent in tuning
> bgwriter behavior,
One argument for it is to avoid writing very hot pages.
> (3) Change the meaning of bgwriter_percent, per Simon's proposal. Make
> it mean "the percentage of the buffer pool to scan, at most, to look for
> dirty buffers". I don't think this is workable, at least not at this
a la long I think we want to avoid that checkpoint needs to do a lot of
writing, without writing hot pages too often. This can only reasonably be
defined with a max number of pages we want to allow dirty at checkpoint time.
bgwriter_percent comes close to this meaning, although in this sense the value
would need to be high, like 80%.
I think we do want 2 settings. Think of one as a short time value
(so bgwriter does not write everything in one run) and one a long term
target over multiple runs.
Is it possible to do a patch that produces a dirty buffer list in LRU order
and stops early when eighter maxpages is reached or bgwriter_percent
pages are scanned ?
Andreas