Skip site navigation (1) Skip section navigation (2)

Re: Latch for the WAL writer - further reducing idle wake-ups.

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Latch for the WAL writer - further reducing idle wake-ups.
Date: 2012-05-03 06:14:04
Message-ID: 4FA2222C.7060705@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 03.05.2012 03:41, Robert Haas wrote:
> On Wed, May 2, 2012 at 7:21 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-05-03 08:43:57
Subject: Re: Advisory locks seem rather broken
Previous:From: Jim NasbyDate: 2012-05-03 05:58:15
Subject: Re: Future In-Core Replication

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group