Re: Doubt in pgbench TPS number - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Doubt in pgbench TPS number
Date
Msg-id alpine.DEB.2.10.1509252012540.8351@sto
Whole thread Raw
In response to Re: Doubt in pgbench TPS number  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Doubt in pgbench TPS number
Re: [HACKERS] Doubt in pgbench TPS number
List 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 
clients.

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).

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Dmitry Chichkov
Date:
Subject: How to get value of 'Param' of the WHERE clause in the FDW?
Next
From: Peter Geoghegan
Date:
Subject: Re: Less than ideal error reporting in pg_stat_statements