Re: Latch for the WAL writer - further reducing idle wake-ups. - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Latch for the WAL writer - further reducing idle wake-ups.
Date
Msg-id 4FA2222C.7060705@enterprisedb.com
Whole thread Raw
In response to Re: Latch for the WAL writer - further reducing idle wake-ups.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Future In-Core Replication
Next
From: Simon Riggs
Date:
Subject: Re: Advisory locks seem rather broken