On 04.01.2012 07:58, Peter Geoghegan wrote:
As part of the ongoing effort to reduce wake-ups when idle/power consumption, the attached patch modifies the background writer to hibernate in ten second bursts once the bgwriter laps the clock sweep. It's fairly well commented, so a description of how it works here would probably be redundant. The most controversial aspect of this patch is the fact that it adds a SetLatch() call to MarkBufferDirty(), though I went to some lengths to ensure that that call will very probably find the latch already set when it actually matters, so it only checks a single flag.
I think SetBufferCommitInfoNeedsSave() needs the same treatment as MarkBufferDirty(). And it would probably be good to only set the latch if the buffer wasn't dirty already. Setting a latch that's already set is fast, but surely it's even faster to not even try.
Thoughts? I can produce benchmarks, if that helps, but I think it's fairly unlikely that the patch introduces a measurable performance regression.
Yeah, I'd like to see a micro-benchmark of a worst-case scenario. I'm a bit worried about the impact on systems with a lot of CPUs. If you have a lot of CPUs writing to the same cache line that contains the latch's flag, that might get expensive.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
