From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Doubt in pgbench TPS number |
Date: | 2015-09-25 04:53:47 |
Message-ID: | 20150925.135347.2220251278958747939.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Today I got an interesting output from pgbench.
The scenario is executing SELECT pg_sleep(0.1).
$ cat test.sql
select pg_sleep(0.1);
$ pgbench -C -n -p 11002 -c 10 -T 30 -f test.sql test
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 30 s
number of transactions actually processed: 2883
latency average: 104.058 ms
tps = 95.799114 (including connections establishing)
tps = 124.487149 (excluding connections establishing)
Interesting thing is, the number from "excluding connections
establishing". 124.487149 tps means 0.008032 seconds per
transaction. Since the query executes pg_sleep(0.1), I think the
number should be equal to or greater than 0.1. Maybe a tolerance, but
20% of error seems to be too high for me.
Note that if "-C" does not present, the TPS number seems to be sane.
$ pgbench -n -p 11002 -c 10 -T 30 -f test.sql test
transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 30 s
number of transactions actually processed: 2970
latency average: 101.010 ms
tps = 98.692514 (including connections establishing)
tps = 98.747053 (excluding connections establishing)
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-09-25 04:55:36 | Re: Parallel Seq Scan |
Previous Message | Amit Kapila | 2015-09-25 04:00:11 | Re: Parallel Seq Scan |