> Yes, with this design, that's true. Under what circumstances
> would this be a problem? Most applications use a transaction
> in conjunction with a human interaction, and for human's,
> 200 ms is literally a blink of the eye. What kinds of
> applications depend on single thread transaction rate (say,
> other than badly structured benchmarks)? Group commits could
> always be turned off, but maybe there's something smarter we
> could do if we had a better understanding of the problem.

Not everything is driven by human interaction (or at least not
every step of a process).

A couple of thoughts...

- DDL scripts (with AUTODDL turned on)

- batch processes that may be trying to commit each item
(Batch processes may commit each item for various reasons, eg:
the size of the batch is unknown so commit may be done at each
item to ensure transactions dont run too long.)

- automation based on mechanistic input events, such as a
database that commits individual meter readings

Each of these can be seen as a reason to have group commit
control at the transaction tpb level. The performance "boost"
of group commits should be able to be explicitly turned off
while there is activity that depends on immediate commit (even
if that is at the expense of others).

In most instances such activities are of limited duration, so
a server or database level of control is too coarse.

--
Geoff Worboys
Telesis Computing