Preliminary results from experimenting with an
N-transactions-must-be-running-to-cause-commit-delay heuristic are
attached. It seems to be a pretty definite win. I'm currently running
a more extensive set of cases on another machine for comparison.
The test case is pgbench, unmodified, but run at scalefactor 10
to reduce write contention on the 'branch' rows. Postmaster
parameters are -N 100 -B 1024 in all cases. The fsync-off (with,
of course, no commit delay either) case is shown for comparison.
"commit siblings" is the number of other backends that must be
running active (unblocked, at least one XLOG entry made) transactions
before we will do a precommit delay.
commit delay=1 is effectively commit delay=10000 (10msec) on this
hardware. Interestingly, it seems that we can push the delay up
to two or three clock ticks without degradation, given positive N.
regards, tom lane
