Re: Doubt in pgbench TPS number

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Doubt in pgbench TPS number
Date: 2015-09-25 18:35:45
Message-ID: alpine.DEB.2.10.1509252012540.8351@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Tatsuo,

> Hmmm... I never use -C. The formula seems ok:
> tps_exclude = normal_xacts / (time_include -
> (INSTR_TIME_GET_DOUBLE(conn_total_time) / nthreads));

Hmmm... it is not:-)

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, even if it is in the
same thread, so it is not "stopped time" for all clients. It starts to
matter with "-j 1 -c 30" and slow transactions, the cumulated conn_time in
each thread may be arbitrary close to the whole time if there are many

Now, I do not think that this tps computation makes that much sense. If
you want to know the tps without reconnect, run without reconnecting... It
is clear that I do not get this figure when running without -C, so maybe
the tps with/without reconnection should be dropped?

Anyway, here is a patch, which:
- fixes the "exclude" computation (s/nthreads/nclients/)
- fixes the count total for skipped (s/threads/thread/)
- removes a useless parameter to doCustom
(the conn_time is available through the thread parameter).


Attachment Content-Type Size
pgbench-connect-1.patch text/x-diff 2.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-09-25 18:37:41 Re: Less than ideal error reporting in pg_stat_statements
Previous Message Dmitry Chichkov 2015-09-25 18:33:18 How to get value of 'Param' of the WHERE clause in the FDW?