Re: [PATCH] add --progress option to pgbench (submission 3) - Mailing list pgsql-hackers

From KONDO Mitsumasa
Subject Re: [PATCH] add --progress option to pgbench (submission 3)
Date
Msg-id 51CBA0B1.6030701@lab.ntt.co.jp
Whole thread Raw
In response to Re: [PATCH] add --progress option to pgbench (submission 3)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [PATCH] add --progress option to pgbench (submission 3)
List 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








pgsql-hackers by date:

Previous
From: Josh Kupershmidt
Date:
Subject: Re: fixing pg_ctl with relative paths
Next
From: Tom Lane
Date:
Subject: Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]