"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