Re: BGWriter latch, power saving

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BGWriter latch, power saving
Date: 2012-01-17 10:16:34
Message-ID: 4F154A82.3040008@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04.01.2012 17:05, Peter Geoghegan wrote:
> On 4 January 2012 07:24, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> 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.
>
> That seems reasonable. Revised patch is attached.

Thanks! It occurs to me that it's still a bad idea to call SetLatch()
while holding the buffer header spinlock. At least when it's trivial to
just move the call after releasing the lock. See attached.

Could you do the sleeping/hibernating logic all in BgWriterNap()?

>> 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.
>
> Also reasonable, but I don't think that I'll get around to it until
> after the final commitfest deadline.

That's still pending. And I admit I haven't tested my updated version
besides "make check".

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Attachment Content-Type Size
bgwriter-latch-v3.patch text/x-diff 11.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-01-17 10:31:47 Re: WAL Restore process during recovery
Previous Message Daniel Farina 2012-01-17 10:14:53 Re: Should we add crc32 in libpgport?