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.
