Re: Doubt in pgbench TPS number
От | Fabien COELHO |
---|---|
Тема | Re: Doubt in pgbench TPS number |
Дата | |
Msg-id | alpine.DEB.2.10.1509281049170.4252@sto обсуждение исходный текст |
Ответ на | Re: Doubt in pgbench TPS number (Tatsuo Ishii <ishii@postgresql.org>) |
Ответы |
Re: Doubt in pgbench TPS number
Re: Doubt in pgbench TPS number |
Список | pgsql-hackers |
> #5 0x0000000000402b2b in doConnect () at pgbench.c:650 > #6 0x0000000000404591 in doCustom (thread=0x25c2f40, st=0x25c2770, > conn_time=0x25c2f90, logfile=0x0, agg=0x7fffba224260) at pgbench.c:1353 > #7 0x000000000040a1d5 in threadRun (arg=0x25c2f40) at pgbench.c:3581 > #8 0x0000000000409ab4 in main (argc=12, argv=0x7fffba224668) at pgbench.c:3455 Hmm. Ok, whatever the connection position (from doCustom or from threadRun), doConnect would block the thread. On the other hand, if you start several threads, probably those threads which could connect all their client would proceed. What looks to be needed would be some timeout when connecting to the server. >> 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. > > Yeah, that's definitely a bug but I'm afraid the fix will change the > TPS number and may break the backward compatibility. Since we have > lived with bug for years, I hesitate to back port to older stable > branches... My 2¥: I do not think of a good argument to keep wrong tps numbers once it is known that there are plain wrong, especially as it is not a behavioral change as such which could block applications or whatever, just a different number printed at the end of a run. So I would not bother much with upward compatibility consideration in this case. -- Fabien.
В списке pgsql-hackers по дате отправления: