Hello Kyotaro-san,
I think this also shows that "including/excluding connections
establishing" as well as some of the other stats reported pretty
bogus. In the 'before' case a substantial numer of the connections had
not yet been established until the end of the test run!
I see it useful. In most cases we don't care connection time of
pgbench. Especially in the mentioned case the result is just bogus. I
think the reason for "including/excluding connection establishing" is
not that people wants to see how long connection took to establish but
that how long the substantial work took. If each client did run with
continuously re-establishing new connections the connection time would
be useful, but actually all the connections are established at once at
the beginning.
So FWIW I prefer that the barrier is applied by default
Yep.
(that is, it can be disabled)
On reflection, I'm not sure I see a use case for not running the barrier
if it is available.
and the progress time starts at the time all clients has been
established.
Yep, the start time should be set after the connection barrier, and
possibly before a start barrier to ensure that no transaction has started
before the start time: although performance measures are expected to be
slightly false because of how they are measured (measuring takes time),
from a benchmarking perspective the displayed result should be <= the
actual performance.
Now, again, if long benchmarks are run, which for a db should more or less
always be the case, this should not matter much.
starting vacuum...end.
+ time to established 5000 connections: 1323ms
Yep, maybe showing the initial connection time separately.
--
Fabien.
