Re: Doubt in pgbench TPS number - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Doubt in pgbench TPS number
Date
Msg-id alpine.DEB.2.10.1509250712330.21900@sto
Whole thread Raw
In response to Doubt in pgbench TPS number  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: Doubt in pgbench TPS number  (Fabien COELHO <coelho@cri.ensmp.fr>)
List 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.



pgsql-hackers by date:

Previous
From: Jeevan Chalke
Date:
Subject: Re: TEXT vs VARCHAR join qual push down diffrence, bug or expected?
Next
From: Amir Rohan
Date:
Subject: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.