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

From Tatsuo Ishii
Subject Re: Doubt in pgbench TPS number
Date
Msg-id 20150929.115441.1842876940282137889.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Doubt in pgbench TPS number  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Doubt in pgbench TPS number  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: Doubt in pgbench TPS number  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-hackers
> FWIW, I vote with Tatsuo-san.  Such a change will break comparability of
> results with all previous versions, which means it's not something to do
> in minor releases, even if we now believe the previous results were
> somewhat bogus.  Arguing that it's "not a behavioral change" seems
> quite loony to me: for most people, the TPS numbers are the only
> interesting output of pgbench.
> 
> I think we should fix it in 9.5 and document it as an incompatible change.

Plus if 9.4 or earlier version of PostgreSQL user wants to use fixed
version of pgbench, he/she can always use pgbench coming with 9.5 or
later version of PostgreSQL.

> (Note: I've not read the patch, so this is not an opinion about its
> correctness.)

As Fabien anayzed the problem was that pgbench simply uses wrong
variable: nthreads (number of threads, specified by "-j" option)
vs. nclients (number of clients, specified by "-c" option).

@@ -2616,7 +2616,7 @@ printResults(int ttype, int64 normal_xacts, int nclients,    time_include =
INSTR_TIME_GET_DOUBLE(total_time);   tps_include = normal_xacts / time_include;    tps_exclude = normal_xacts /
(time_include-
 
-                        (INSTR_TIME_GET_DOUBLE(conn_total_time) / nthreads));
+                        (INSTR_TIME_GET_DOUBLE(conn_total_time) / nclients));

Here conn_total_time is the sum of time to establish connection to
PostgreSQL. Since establishing connections to PostgreSQL is done in
serial rather than in parallel, conn_total_time should have been
divided by nclients.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Rework the way multixact truncations work
Next
From: Jim Nasby
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!