From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Steve Singer <steve(at)ssinger(dot)info>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] pgbench regression test failure |
Date: | 2017-11-20 22:15:14 |
Message-ID: | alpine.DEB.2.20.1711202255090.15686@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-11-20 22:19:30 | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |
Previous Message | Alexander Korotkov | 2017-11-20 22:07:37 | Re: [HACKERS] CUBE seems a bit confused about ORDER BY |