> -----Original Message-----
> From: Tom Lane
>
> 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.
>
> My initial try at this proved to be too noisy to tell much. The noise
> seems to be coming from WAL checkpoints that occur during a run and
> push down the reported TPS value for the particular case that's running.
> While we'd need to include WAL checkpoints to make an honest performance
> comparison against another RDBMS, I think they are best ignored for the
> purpose of figuring out what the commit-delay behavior ought to be.
> Accordingly, I modified my test script to minimize the occurrence of
> checkpoint activity during runs (see attached script). There are still
> some data points that are unexpectedly low compared to their neighbors;
> presumably these were affected by checkpoints or other system activity.
>
> 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.)
>
> Comments anyone?
>
How about the case with scaling factor 1 ? i.e Could your
proposal detect lock conflicts in reality ? If so, I agree with
your proposal.
BTW there seems to be a misunderstanding about CommitDelay,
i.e
CommitDelay is completely a waste of time unless there's an overlap of commit.
If other backends use the delay(cpu cycle) the delay is never
a waste of time totally.
Regards,
Hiroshi Inoue
