On Mon, Sep 15, 2014 at 6:34 AM, Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
