>> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
