Re: pgbench: option delaying queries till connections establishment?

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.