From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Doubt in pgbench TPS number |
Date: | 2015-09-25 05:28:09 |
Message-ID: | alpine.DEB.2.10.1509250712330.21900@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Tatsuo-san,
> $ pgbench -C -n -p 11002 -c 10 -T 30 -f test.sql test
> 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.
Indeed.
> Note that if "-C" does not present, the TPS number seems to be sane.
Hmmm... I never use -C. The formula seems ok:
tps_exclude = normal_xacts / (time_include -
(INSTR_TIME_GET_DOUBLE(conn_total_time) / nthreads));
conn_total_time is the cumulated time spent by all threads.
A quick look at the logic reveals some minor issues (conn_time is passed
as an argument to doCustom, although it is already available as a "thread"
field, stange). I spotted "threads" used instead of "thread" in an
accumulation, but it is not related to this computation.
Hmmm. I'll have a slower look...
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Amir Rohan | 2015-09-25 06:11:33 | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
Previous Message | Jeevan Chalke | 2015-09-25 05:27:16 | Re: TEXT vs VARCHAR join qual push down diffrence, bug or expected? |