Re: Re: [BUGS] Problem in using pgbench's --connect(-C)and --rate=rate(-R rate) options together. - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Re: [BUGS] Problem in using pgbench's --connect(-C)and --rate=rate(-R rate) options together.
Date
Msg-id alpine.DEB.2.20.1703241557210.28545@lancre
Whole thread Raw
In response to Re: [HACKERS] Re: [BUGS] Problem in using pgbench's --connect(-C) and--rate=rate(-R rate) options together.  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: Re: [BUGS] Problem in using pgbench's --connect(-C) and--rate=rate(-R rate) options together.
List pgsql-hackers
Hello Teodor,

> Hi, the patch looks good except why do you remove initialization of 
> is_throttled? Suppose, just a typo?

No, it is really needed so that the lag measure is correct.

Without the is_throttled change:
 sh> ./pgbench -T 3 -R 10 -C -S -P 1 starting vacuum...end. progress: 1.0 s, 9.0 tps, lat 8.278 ms stddev 9.134, lag
2049638230412146.250ms progress: 2.0 s, 12.0 tps, lat 4.897 ms stddev 3.961, lag 2.219 ms transaction type: <builtin:
selectonly> scaling factor: 1 query mode: simple number of clients: 1 number of threads: 1 duration: 3 s number of
transactionsactually processed: 33 latency average = 5.602 ms latency stddev = 5.820 ms rate limit schedule lag: avg
558992244657859.500(max 18446744073709264.000) ms tps = 11.024559 (including connections establishing) tps = 12.183456
(excludingconnections establishing)
 

With the is_throttled change:
 ./pgbench -T 3 -R 10 -C -S -P 1 starting vacuum...end. progress: 1.0 s, 11.0 tps, lat 3.742 ms stddev 2.161, lag 1.658
msprogress: 2.0 s, 7.0 tps, lat 2.985 ms stddev 0.496, lag 0.276 ms transaction type: <builtin: select only> scaling
factor:1 query mode: simple number of clients: 1 number of threads: 1 duration: 3 s number of transactions actually
processed:25 latency average = 3.312 ms latency stddev = 1.518 ms rate limit schedule lag: avg 0.894 (max 7.031) ms tps
=8.398353 (including connections establishing) tps = 9.069456 (excluding connections establishing)
 

-- 
Fabien.



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: pg_stat_wal_write statistics view
Next
From: David Steele
Date:
Subject: Re: LWLock optimization for multicore Power machines