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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to