Re: commit_delay, siblings

"Josh Berkus" <josh@agliodbs.com> writes
> Hackers:
>
> I've been trying to get a test result for 8.1 that shows that we can
eliminate
> commit_delay and commit_siblings, as I believe that these settings no
longer
> have any real effect on performance.  However, the checkpointing
performance
> issues have so far prevented me from getting a good test result for this.
>

In my understadning, the commit_delay/commit_siblings combination simulate
the background xlog writer mechanisms in some database like Oracle.

This might be separate issue. We have code in xlogflush() like:
/* done already? */if (!XLByteLE(record, LogwrtResult.Flush)){ /* now wait for the write lock */
LWLockAcquire(WALWriteLock,LW_EXCLUSIVE); if (XLByteLE(record, LogwrtResult.Flush))     LWLockRelease(WALWriteLock);
/*if done already, then release the
 
lock */ else    /* do it */

If the testing results turns out the "LWLockRelease(WALWriteLock)" actually
happened often, then it indicates that we waste some time on acquiring
WALWriteLock. Would commit_delay/commit_siblings helps or we need a
background xlog writer and notify us the completion of xlogflush is better
(so we don't compete for this lock)?

Regards,
Qingqing