"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

Reply via email to