Re: [HACKERS] pgbench regression test failure
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pgbench regression test failure |
Дата | |
Msg-id | alpine.DEB.2.20.1711202255090.15686@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench regression test failure (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: