(2013/06/28 3:17), Fabien COELHO wrote:
Attached is patch version 5.
It includes this solution for fork emulation, one report per thread instead of a
global report. Some code duplication for that.
It's good coding. I test configure option with --disable-thread-safety and not.
My test results
Dear Mitsumasa,
I have small comments. I think that 'lat' is not generally abbreviation
of 'latency'. But I don't know good abbreviation. If you have any good
abbreviation, please send us revise version.
I needed something short, because I may add a lag time as well under
throttling. No
Hi, Febien
Thanks for your fast response and fix! I set your patch ready for commiter now.
(2013/07/01 19:49), Fabien COELHO wrote:
I have small comments. I think that 'lat' is not generally abbreviation of
'latency'. But I don't know good abbreviation. If you have any good
abbreviation,
Dear Febien
(2013/06/27 14:39), Fabien COELHO wrote:
If I show a latency at full load, that would be nclients/tps, not 1/tps.
However, I'm hoping to pass the throttling patch to pgbench, in which case the
latency to show is a little bit different because the nclients/tps would
include sleep
On Wed, Jun 26, 2013 at 7:16 AM, Fabien COELHO coe...@cri.ensmp.fr 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
Dear Robert,
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.
I don't believe that to be an
Fabien COELHO coe...@cri.ensmp.fr writes:
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.
I
Otherwise, he simplest possible adaptation, if it is required to have the
progress feature under fork emulation to pass it, is that under fork
emulation each processus reports its current progress instead of having a
collective summing.
Perhaps that's worth doing. I agree with Fabien that
Dear Matsumasa,
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.
However I've kept the
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
Dear Mitsumasa,
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.
Sure. I agree that both
Hello Mitsumasa,
Thanks for the review.
* 2. Output format in result for more readable.
5.0 s[thread 1]: tps = 1015.576032, AverageLatency(ms) = 0.000984663
5.0 s[thread 0]: tps = 1032.580794, AverageLatency(ms) = 0.000968447
10.0 s [thread 0]: tps = 1129.591189, AverageLatency(ms) =
Hi Febien,
I send you my review result and refactoring patch. I think that your patch has
good function and many people surely want to use! I hope that my review comment
will be good for your patch.
* 1. Complete words and variable in source code and sgml document.
It is readable for user
New submission which put option help in alphabetical position, as
per Peter Eisentraut f0ed3a8a99b052d2d5e0b6153a8907b90c486636
This is for reference to the next commitfest.
Patch update after conflict induced by pg-indentation, for the next
commitfest.
--
Fabien.diff --git
14 matches
Mail list logo
