On Tue, May 7, 2013 at 8:13 AM, Amit Langote <amitlangote09@gmail.com> wrote:
> Profiling results show that XLogFlush() is called about twice as many
> times after this patch while for XLogWrite() count remains about same
> as before. This patch modifies XLogFlush() such that it offers the
> said performance gain by alleviating the lock contention on
> WALWriteLock using the new LWLockAcquireOrWait(). I do not however
> understand why XLogFlush is invoked twice as many times (as seen from
> the profiling results) as an effect of this patch. Why should this
> patch make XLogFlush() being invoked twice as many times?
Why is that surprising? Most of those XLogFlush() calls will recheck
the flushed-up-to point, and realize that another backend assumed the
role of group commit leader, and flushed their WAL for them, so aside
from the wait, the call to XLogFlush is cheap for that individual
backend. It's being invoked twice as many times because backends *can*
invoke it twice as many times.
For the record, the new group commit code did more than just alleviate
lock contention. If it was true that amelioration of lock contention
fully explained the improvements, then surely sleeping on an exclusive
lock on WALWriteLock within XLogFlush would always hurt throughput,
when in fact it can considerably help throughput, as demonstrated by
9.3's commit_delay implementation.
--
Peter Geoghegan