"Josh Berkus" <[email protected]> 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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
