Re: Doubt in pgbench TPS number
От | Fabien COELHO |
---|---|
Тема | Re: Doubt in pgbench TPS number |
Дата | |
Msg-id | alpine.DEB.2.10.1509280949110.4252@sto обсуждение исходный текст |
Ответ на | Re: Doubt in pgbench TPS number (Tatsuo Ishii <ishii@postgresql.org>) |
Ответы |
Re: Doubt in pgbench TPS number
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: