Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > First, we remove the GUC bgwriter_maxpages because I don't see a good > > way to set a default for that. A default value needs to be based on a > > percentage of the full buffer cache size. > > This is nonsense. The admin knows what he set shared_buffers to, and so > maxpages and percent of shared buffers are not really distinct ways of > specifying things. The cases that make a percent spec useful are if > (a) it is a percent of a non-constant number (eg, percent of total dirty > pages as in the current code), or (b) it is defined in a way that lets > it limit the amount of scanning work done (which it isn't useful for in > the current code). But a maxpages spec is useful for (b) too. More to > the point, maxpages is useful to set a hard limit on the amount of I/O > generated by the bgwriter, and I think people will want to be able to do > that.
I figured that if we specify a percentage users would not need to update this value regularly if they increase their shared buffers. I agree if you want to limit total I/O by the bgwriter an actual pages a count is better but I assumed we were looking for bgwriter to do a certain percentage of total writes. If the system is doing a lot of writes then limiting the bgwriter doesn't help because then the backends are going to have to do the writes themselves. > > Now, to control the bgwriter frequency we multiply the percent of the > > list it had to span by the bgwriter_delay value to determine when to run > > bgwriter next. > > I'm less than enthused about this. The idea of the bgwriter is to > trickle out writes in a way that doesn't affect overall performance too > much. Not to write everything in sight at any cost. No question my idea makes tuning diffcult. I was hoping it would be self-tuning but I am not sure. > I like the hybrid "keep the bottom of the ARC list clean, plus do a slow > clock scan on the main buffer array" approach better. I can see that > that directly impacts both of the goals that the bgwriter has. I don't > see how a variable I/O rate really improves life on either score; it > just makes things harder to predict. So what are we doing for 8.0? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
