Re: Why do we still have commit_delay and commit_siblings?

On 14.05.2012 02:17, Peter Geoghegan wrote:
> One illuminating way of quickly explaining the new group commit code
> is that it also inserts a delay at approximately the same place (well,
> more places now, since the delay was previously inserted only at the
> xact.c callsite of XLogFlush(), and there are plenty more sites than
> that), only that delay is now just about perfectly adaptive. That
> isn't quite the full truth, since we *also* have the benefit of
> *knowing* that there is an active leader/flusher at all times we're
> delayed. The unusual semantics of LWLockAcquireOrWait() result in the
> new 9.2 code almost always just causing a delay for most backends when
> group commit matters (that is, a delay before they reach their final,
> "productive" iteration of the for(;;) loop for the commit, usually
> without them ever actually acquiring the exclusive
> lock/XlogWrite()'ing).

That doesn't seem like an accurate explanation of how the code works. It
doesn't insert a deliberate delay anywhere. At a high level, the
algorithm is exactly the same as before. However, the new code improves
the concurrency of noticing that the WAL has been flushed. If you had a
machine where context switches are infinitely fast and has zero
contention from accessing shared memory, the old and new code would
behave the same.

It was an impressive improvement, but the mechanism is completely
different from commit_delay and commit_siblings.

That said, I wouldn't mind removing commit_delay and commit_siblings.
They're pretty much impossible to tune correctly, assuming they work as
advertised. Some hard data would be nice, though, as Robert suggested.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com