On 03.05.2012 03:41, Robert Haas wrote:
On Wed, May 2, 2012 at 7:21 PM, Tom Lane<t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
