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

On Wed, May 2, 2012 at 7:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It is getting a bit late to be considering such changes for 9.2, but
> I'm willing to review and commit this if there's not anybody who feels
> strongly that it's too late.  Personally I think it's in the nature of
> cleanup and so fair game as long as we haven't formally started beta.
> However I will confess to some bias about wanting to get the server's
> idle wake-up rate down, because Fedora people have been bugging me
> about that for a long time now.  So I'm probably not the best person to
> objectively evaluate whether we should hold this for 9.3.  Comments?

Well, I feel that one of the weaknesses of our CommitFest process is
that changes like this (which are really pretty small) end up having
the same deadline as patches that are large (command triggers,
checksums, etc.); in fact, they sometimes end up having an earlier
deadline, because the people doing the big stuff end up continuing to
hack on it for another couple months while the door is shut to smaller
improvements.  So I'm not going to object if you feel like slipping
this one in.  I looked it over myself and I think it's broadly
reasonable, although I'm not too sure about the particular criteria
chosen for sending the WAL writer to sleep and waking it up again.
And like you I'd like to see some more improvement in this area.

> 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.  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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company