On Mon, Sep 15, 2014 at 6:34 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> Please have a look. I have not looked at the docs changes yet.
>
> One thing that needs some thinking and changing is the progress reporting.
> It currently looks like this:
>
> progress: 1.0 s, 4863.0 tps, lat 3.491 ms stddev 2.487, lag 1.809 ms, 99
> skipped
> progress: 2.0 s, 5042.8 tps, lat 3.265 ms stddev 2.264, lag 1.584 ms, 16
> skipped
> progress: 3.0 s, 4926.1 tps, lat 2.731 ms stddev 2.371, lag 1.196 ms, 45
> skipped
> progress: 4.0 s, 4963.9 tps, lat 1.904 ms stddev 1.212, lag 0.429 ms, 0
> skipped
> progress: 5.0 s, 4971.2 tps, lat 2.592 ms stddev 1.722, lag 0.975 ms, 0
> skipped
>
> The absolute number of skipped transactions doesn't make much sense when all
> the other numbers are averages, and tps is a 1/s value. If you don't know
> the total number of transactions executed, the absolute number is
> meaningless. (Although you can calculate the absolute number of transactions
> executed by multiplying the TPS value with the interval). I think a
> percentage would be better here.
>
> Should we also print the number of late transactions here? I think that
> would be an even more important detail than the number of skipped
> transactions. It might be better to print only the percentage of late
> transactions, including skipped ones. Or both, but it's difficult to cram
> everything on a single line. This needs some further thinking..
I'm not sure I like the idea of printing a percentage. It might be
unclear what the denominator was if somebody feels the urge to work
back to the actual number of skipped transactions. I mean, I guess
it's probably just the value you passed to -R, so maybe that's easy
enough, but then why bother dividing in the first place? The user can
do that easily enough if they want the data that way.
I agree with you that it would be good to get some statistics on
late/skipped transactions, but it's not obvious what people will want.
Late transactions, straight up? Late by more than a threshold value?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company