Hello Andres,
> Therefore I'd like to make pgbench wait till it has established all
> connections, before they run queries.
> Does anybody else see this as being useful?
Yes, I think that having this behavior available would make sense.
> If so, should this be done unconditionally?
Dunno. I should think about it. I'd say probably.
Pgbench is more or less designed to run a long hopefully steady-state
benchmark, so that the initial connection setup is always negligeable. Not
complying with this hypothesis quite often leads to weird results.
> A new option?
Maybe, if not unconditional.
If there is an unconditional barrier, the excluding/including connection
stuff does not make a lot of sense when not under -C, if it did make any
sense before…
> Included in an existing one somehow?
Which one would you suggest?
Adding a synchronization barrier should be simple enough, I thought about
it in the past.
However, I'd still be wary that it is no silver bullet: if you start a lot
of threads compared to the number of available cores, pgbench would
basically overload the system, and you would experience a lot of waiting
time which reflects that the client code has not got enough cpu time.
Basically you would be testing the OS process/thread management
performance.
On my 4-core laptop, with a do-nothing script (\set i 0):
sh> pgbench -T 10 -f nope.sql -P 1 -j 10 -c 10
latency average = 0.000 ms
latency stddev = 0.049 ms
tps = 21048841.630291 (including connections establishing)
tps = 21075139.938887 (excluding connections establishing)
sh> pgbench -T 10 -f nope.sql -P 1 -j 100 -c 100
latency average = 0.002 ms
latency stddev = 0.470 ms
tps = 23846777.241370 (including connections establishing)
tps = 24132252.146257 (excluding connections establishing)
Throughput is slightly better, latency average and variance explode
because each thread is given stretches of cpu time to advance, then wait
for the next round of cpu time.
--
Fabien.
