Re: pgbench: option delaying queries till connections establishment?

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench: option delaying queries till connections establishment?
Date: 2020-02-29 14:29:19
Message-ID: alpine.DEB.2.21.2002291504100.25187@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

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.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2020-02-29 14:39:06 Re: pgbench: option delaying queries till connections establishment?
Previous Message Alexey Kondratov 2020-02-29 12:35:27 Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly