On Sun, Feb 25, 2001 at 12:41:28AM -0500, Tom Lane wrote:
> Attached are graphs from more thorough runs of pgbench with a commit
> delay that occurs only when at least N other backends are running active
> transactions. ...
> It's not entirely clear what set of parameters is best, but it is
> absolutely clear that a flat zero-commit-delay policy is NOT best.
>
> The test conditions are postmaster options -N 100 -B 1024, pgbench scale
> factor 10, pgbench -t (transactions per client) 100. (Hence the results
> for a single client rely on only 100 transactions, and are pretty noisy.
> The noise level should decrease as the number of clients increases.)
It's hard to interpret these results. In particular, "delay 10k, sibs 20"
(10k,20), or cyan-triangle, is almost the same as "delay 50k, sibs 1"
(50k,1), or green X. Those are pretty different parameters to get such
similar results.
The only really bad performers were (0), (10k,1), (100k,20). The best
were (30k,1) and (30k,10), although (30k,5) also did well except at 40.
Why would 30k be a magic delay, regardless of siblings? What happened
at 40?
At low loads, it seems (100k,1) (brown +) did best by far, which seems
very odd. Even more odd, it did pretty well at very high loads but had
problems at intermediate loads.
Nathan Myers
ncm@zembu.com
