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