Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> (BTW, the patch seems >> a bit schizoid about whether checkpoint_rate is int or float.)
> Yeah, I've gone back and forth on the data type. I wanted it to be a > float, but guc code doesn't let you specify a float in KB, so I switched > it to int. I seriously question trying to claim that it's blocks at all, seeing that the *actual* units are pages per unit time. Pretending that it's a memory unit does more to obscure the truth than document it. >> What's bugging me about this is that we are either going to be writing >> at checkpoint_rate if ahead of schedule, or max possible rate if behind; >> that's not "smoothing" to me, that's introducing some pretty bursty >> behavior. > That sounds a lot more complex. The burstiness at that level shouldn't > matter much. The OS is still going to cache the writes, and should even > out the bursts. With the changes you're proposing here, the burstiness would be quite severe. OTOH, if writes_per_nap is always 1, then bufmgr is going to recheck the delay situation after every page, so what you have actually tested is as granular as it could get. >> And checkpoint_rate really needs to be named checkpoint_min_rate, if >> it's going to be a minimum. However, I question whether we need it at >> all, > Hmm. With bgwriter_delay of 200 ms, and checkpoint_min_rate of 512 KB/s, > using the non-broken formula above, we get: > (512*1024/8192) * 200 / 1000 = 12.8, truncated to 12. > So I think that's fine. "Fine?" That's 12x the value you have actually tested. That's enough of a change to invalidate all your performance testing IMHO. I still think you've not demonstrated a need to expose this parameter. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings