On Sat, Oct 5, 2013 at 6:10 PM, Noah Misch n...@leadboat.com wrote:
The sum of the squares of the latencies wraps after 2^63/(10^12 * avg_latency
* nclients) seconds. That's unlikely to come up with the ordinary pgbench
script, but one can reach it in a few hours when benchmarking a command
pgbench already offers two schedules of pgbench --initialize messaging,
message-per-100k-rows and message-per-5s. A user too picky to find
satisfaction in either option can filter the messages through grep, sed et al.
We patched pgbench on two occasions during the 9.3 cycle to arrive at that
On Sat, Oct 5, 2013 at 6:10 PM, Noah Misch n...@leadboat.com wrote:
The sum of the squares of the latencies wraps after 2^63/(10^12 * avg_latency
* nclients) seconds. That's unlikely to come up with the ordinary pgbench
script, but one can reach it in a few hours when benchmarking a command
Hello Noah,
Patch (4): Redefine latency as reported by pgbench and report lag more.
Here is a first partial patch, which focusses on measuring latency
and reporting the measure under --progress.
This patch contains the features pertaining to both hypothetical patches (3)
and (4), not just
On Sun, Oct 06, 2013 at 09:40:40AM +0200, Fabien COELHO wrote:
Which part do you want as a next step?
I think we're done; here are the distinct changes in your original patch,
along with their dispositions:
Patch (1): Change the default from --progress=0 to --progress=5
Rejected
Patch
Hello Noah,
Patch (1): Change the default from --progress=0 to --progress=5
Rejected
Yep. Too bad, esp as the default is meaningless and does not scale.
Patch (2): Make --initialize mode respect --progress.
Rejected
I missed this one...
This is just about having the same option
On Sun, Oct 06, 2013 at 05:04:56PM +0200, Fabien COELHO wrote:
Patch (2): Make --initialize mode respect --progress.
Rejected
I missed this one...
See the second half of this message, including quoted material:
Patch (2): Make --initialize mode respect --progress.
Rejected
I missed this one...
See the second half of this message, including quoted material:
http://www.postgresql.org/message-id/CA+TgmoZNXkm-EtszHX=kwq34h5ni4cs8dg31no86cmdryaq...@mail.gmail.com
I did not read Peter Haas comments as
On Sun, Oct 06, 2013 at 06:44:11PM +0200, Fabien COELHO wrote:
Patch (2): Make --initialize mode respect --progress.
Rejected
I missed this one...
See the second half of this message, including quoted material:
On Thu, Sep 26, 2013 at 08:50:15PM +0200, Fabien COELHO wrote:
Patch (4): Redefine latency as reported by pgbench and report lag more.
Here is a first partial patch, which focusses on measuring latency
and reporting the measure under --progress.
This patch contains the features pertaining
My feelings on the patch split haven't changed; your three bullet points call
for four separate patches. Conflicting patches are bad, but dependent patches
are okay;
Indeed, this is the only solution if you do not want one patch. Note that
it will not possible to backtrack one of the patch
Patch (4): Redefine latency as reported by pgbench and report lag more.
Here is a first partial patch, which focusses on measuring latency and
reporting the measure under --progress.
**
Improve pgbench measurements progress report
Measure transaction latency instead under --rate and
On Tue, Sep 24, 2013 at 10:41:17PM +0200, Fabien COELHO wrote:
These changes are coupled because measures are changed, and their
reporting as well. Submitting separate patches for these different
features would result in conflicting or dependent patches, so I
wish to avoid that if possible.
Split 3 of the initial submission, which actually deal with data measured and
reported on stderr under various options.
This version currently takes into account many comments by Noah Mish. In
particular, the default no report behavior under benchmarking is not
changed, although I really
14 matches
Mail list logo
