Hello Tom,
2. ISTM that we should report that 100% of the transactions were
above the latency limit, not 33%; that is, the appropriate base
for the "number of transactions above the latency limit" percentage
is the number of actual transactions not the number of scheduled
transactions.
Hmmm. Allow me to disagree.
I dunno, it just looks odd to me that when we've set up a test case in
which every one of the transactions is guaranteed to exceed the latency
limit, that it doesn't say that they all did. I don't particularly buy
your assumption that the percentages should sum.
This is a side effect. The reason for me is that the user asked for some
transactions, and the results should be given relative to what was asked.
Anybody else have an opinion there?
Good question.
I also noticed that if I specify "-f sleep-100.sql" more than once,
the per-script TPS reports are out of line. This is evidently because
that calculation isn't excluding skipped xacts; but if we're going to
define tps as excluding skipped xacts, surely we should do so there too.
I do not think that we should exclude skipped xacts.
Uh ... why not?
Because I totally misinterpreted your sentence.
Indeed, the skipped transactions needs to be substracted from the count.
This is yet another bug.
but I find that unduly optimistic. It should really read more like
"if no transactions were executed, at best we'll get some platform-
dependent spelling of NaN. At worst we'll get a SIGFPE."
Hmmm. Alas you must be right about spelling. There has been no report of
SIGFPE issue, so I would not bother with that.
The core issue here really is that you're assuming IEEE float arithmetic.
We have not gone as far as deciding that Postgres will only run on IEEE
hardware, and I don't want to start in pgbench, especially not in
seldom-exercised corner cases.
Hmmm. It has already started for some years without complaint. Do as you
feel about NaN. I can only say that I do not like much having zero to
stand for undefined.
--
Fabien.
