On 03.05.2012 03:41, Robert Haas wrote:
> On Wed, May 2, 2012 at 7:21 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> Adding any contention at all to XLogInsert doesn't seem like a smart
>> idea, even if you failed to measure any problem in the specific tests
>> you made. I wonder whether we could not improve matters by adding
>> an additional bool "wal_writer_needs_wakening" in the state that's
>> considered to be protected by WALInsertLock.
>
> I am skeptical about this, although it could be right. It could also
> be better the way Peter did it; a fetch of an uncontended cache line
> is pretty cheap.
I'm very wary of adding any extra shared memory accesses to XLogInsert.
I spent a lot of time trying to eliminate them in my XLogInsert scaling
patch. It might be ok if the flag is usually not modified, and we don't
add any extra barrier instructions in there, but it would be better to
avoid it.
One simple idea would be to only try to set the latch every 100
XLogInsert calls in the backend. That would cut whatever contention it
might cause by a factor of 100, making it negligible.
> Another approach - which I think might be better
> still - is to not bother kicking the WAL writer and let it wake up
> when it wakes up. Maybe have it hibernate for 3 seconds instead of
> 10, or something like that. It seems unlikely to cause any real
> problem if WAL writer takes a couple seconds to get with the program
> after a long period of inactivity; note that an async commit will kick
> it anyway, and a sync commit will probably half to flush WAL whether
> the WAL writer wakes up or not.
Yeah, that'd be even simpler.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com