Re: Doubt in pgbench TPS number

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: Doubt in pgbench TPS number
Дата
Msg-id alpine.DEB.2.10.1509252012540.8351@sto
обсуждение исходный текст
Ответ на Re: Doubt in pgbench TPS number  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: Doubt in pgbench TPS number  (Tatsuo Ishii <ishii@postgresql.org>)
Re: [HACKERS] Doubt in pgbench TPS number  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Dmitry Chichkov
Дата:
Сообщение: How to get value of 'Param' of the WHERE clause in the FDW?
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Less than ideal error reporting in pg_stat_statements