Hello Tatsuo-san,
I think that the degree of parallelism to consider is nclients, not
nthreads: while connection time is accumulated in conn_time, other
clients are possibly doing their transactions, in parallel,
I'm not sure about this. I think pgbench will not start transactions
until all clients establish connections to PostgreSQL.
I think that is true if "!is_connect", all client connections are
performed at the beginning of threadRun, but under -C each client has its
own connect/deconnect integrated within doCustom, so it is done in
parallel to other clients having their transactions processed, hence the
issue with the formula.
I found this while playing with pgpool-II. pgpool-II pre-forks child
process, whose number is defined by "num_init_children"
directive. What I observed was, pgbench starts connecting to pgpool-II
until "-c" connections are established. So, if "-c" is larger than
"num_init_children", no transaction starts.
Yep, unless -C, I think, where some client may start nevertheless? Not
sure... Does not matter.
I have tested your patch. It seems the tolerance is much better than
before with your patch.
Yep.
I'm going to commit your patch if there's no objection.
This seems fine with me.
The formula change, and just this one, should probably be backported
somehow, as this is a bug, wherever pgbench resides in older versions. It
is just 's/nthreads/nclients/' in the printResult formula for computing
tps_exclude.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
