Re: Doubt in pgbench TPS number

>> 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.

Fix committed to master and 9.5 stable branches.

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