On Thu, Feb 23, 2012 at 3:44 PM, Greg Smith <g...@2ndquadrant.com> wrote: > It's not quite that bad. Once the BGW has circled around the whole buffer > pool, such that it's swept so far ahead it's reached the clock sweep > strategy point, it stops. So when the system is idle, it creeps forward > until it's scanned the pool once. Then, it still wakes up regularly, but > the computation of the bufs_to_lap lap number will reach 0. That aborts > running the main buffer scanning loop, so it only burns a bit of CPU time > and a lock on BufFreelistLock each time it wakes--both of which are surely > to spare if the system is idle. I can agree with your power management > argument, I don't see much of a performance win from eliminating this bit
I think that goal of ending up with a clean buffer pool is a good one, and I'm loathe to give it up. On the other hand, I agree with Simon that it does seem a bit wasteful to scan the entire buffer arena because there's one dirty buffer somewhere. But maybe we should look at that as a reason to improve the way we find dirty buffers, rather than a reason not to worry about writing them out. There's got to be a better way than scanning the whole buffer pool. Honestly, though, that feels like 9.3 material. So far there's no evidence that we've introduced any regressions that can't be compensated for by tuning, and this doesn't feel like the right time to embark on a bunch of new engineering projects. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
