Re: [PATCH] add --progress option to pgbench (submission 3)

From: KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] add --progress option to pgbench (submission 3)
Date: 2013-06-27 02:17:21
Message-ID: 51CBA0B1.6030701@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Fevien,

Thank you for your fast work and reply. I try to test your new patch until next
week.

(2013/06/26 20:16), Fabien COELHO wrote:
> Here is a v4 that takes into account most of your points: The report is performed
> for all threads by thread 0, however --progress is not supported under thread
> fork emulation if there are more than one thread. The report time does not slip
> anymore.
Good! I think that you try to talk to commiter about implimentaion of progress
output in ready for commiter. It is good for patch that giving advices by many
people.

> However I've kept the format scarse. It is a style thing:-) and it is more
> consistent with the kind of format used in the log. I have not added the
> "latency" measure because it is redundant with the tps, and the latency that
> people are expecting is the actual latency of each transactions, not the apparent
> latency of transactions running in parallel, which is really a throuput.
As I know, famous NoSQL benchmark program which was called YCSB is display
latency measure. I think that TPS indicates system performance for system
administrator, and latency indicates service performance for end user, in custom
benchmarks. It might be redundant, but it would be needed by some engineer who
cannot decide to select PostgreSQL or other database such like NoSQL. It is also
good to talk to committer and other people. Objective opinion is important!

Best regards,
--
Mitsumasa KONDO
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-06-27 03:05:44 Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Previous Message Josh Kupershmidt 2013-06-27 01:36:00 Re: fixing pg_ctl with relative paths