From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, pavel(dot)stehule(at)gmail(dot)com |
Subject: | Re: pgbench progress report improvements - split 3 v2 - A |
Date: | 2013-10-05 22:10:02 |
Message-ID: | 20131005221002.GB180956@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 to both hypothetical patches (3)
and (4), not just (4) like I requested.
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 that
runs for many seconds. If we care, we can track the figure as a double. I
merely added a comment about it.
I restored applicable parts of your update to the --progress documentation
from pgbench-measurements-v5.patch.
The patch made output like this:
progress: 7.2 s, 1.7 tps, 205.225 stddev 3.484 ms lat, 45.472 ms lag
I read that as five facts:
7.2 s
1.7 tps
205.225 stddev
3.484 ms lat
45.472 ms lag
That was a wrong reading; 205.225 is the latency average and 3.484 is the
latency standard deviation. Let's be consistent about the placement of labels
relative to their figures. Upthread, had you proposed this format:
progress: 36.0 s, 115.2 tps, lat avg 9.678 ms stddev 1.792, lag 0.143 ms
I switched to that, except that I removed the word "avg" to save horizontal
space and since lag is also an average though not labelled as such.
> + printf("latency average: %.3f ms\n",
> + 1000.0 * duration / normal_xacts);
I incorporated the "nclients" factor needed here.
Committed with those changes.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2013-10-05 22:15:45 | Re: plpgsql.print_strict_params |
Previous Message | Tomas Vondra | 2013-10-05 18:22:54 | custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption |