While playing with 9.5's pgbench, I faced with a strange behavior.
$ pgbench -p 11002 --rate 2 --latency-limit 1 -c 10 -T 10 test
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 10 s
number of transactions actually processed: 16
number of transactions skipped: 0 (0.000 %)
number of transactions above the 1.0 ms latency limit: 16 (100.000 %)
latency average: 5.518 ms
latency stddev: 1.834 ms
rate limit schedule lag: avg 0.694 (max 1.823) ms
tps = 1.599917 (including connections establishing)
tps = 1.600319 (excluding connections establishing)
>From the pgbench manual:
<term><option>--latency-limit=</option><replaceable>limit</></term>
<listitem>
<para>
Transaction which last more than <replaceable>limit</> milliseconds
are counted and reported separately, as <firstterm>late</>.
</para>
<para>
When throttling is used (<option>--rate=...</>), transactions that
lag behind schedule by more than <replaceable>limit</> ms, and thus
have no hope of meeting the latency limit, are not sent to the server
at all. They are counted and reported separately as
<firstterm>skipped</>.
In my understanding, this says: any transaction takes longer than the
duration specified by --latency-limit (in this case 1.0 ms) will not
be sent the sever. In the case above all (16) transactions were behind
the latency limit 1.0 ms:
number of transactions above the 1.0 ms latency limit: 16 (100.000 %)
So the number of skipped transactions should be 16 (100%), rather
than:
number of transactions skipped: 0 (0.000 %)
in this case I think.
Am I missing something?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
