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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
