Re: CommitDelay performance improvement

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> How about the case with scaling factor 1 ? i.e Could your
> proposal detect lock conflicts in reality ?

The code is set up to not count backends that are waiting on locks.
That is, to do a commit delay there must be at least N other backends
that are in transactions, have written at least one XLOG entry in
their transaction (so it's not a read-only xact and will need to
write a commit record), and are not waiting on a lock.

Is that what you meant?

> 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.

Good point. In fact, if we measure only the total throughput in
transactions per second then the commit delay will not appear to be
hurting performance no matter how long it is, so long as other backends
are in the RUN state for the whole delay. This suggests that pgbench
should also measure the average transaction time seen by any one client.
Is that a simple change?

regards, tom lane