Re: [HACKERS] pgbench regression test failure - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] pgbench regression test failure
Date
Msg-id CA+TgmoZ8kbPuPC5ERSC8yqtVNoAp_WgpdDtUEvXLnHB3-CoisA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pgbench regression test failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] pgbench regression test failure  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Nov 20, 2017 at 1:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.  Anybody else have an
> opinion there?

I agree with you, but I don't think either approach is free from
possible confusion.  I think it would help to show the numerator and
the denominator explicitly, e.g.:

number of clients: 1
number of threads: 1
number of transactions per client: 100
number of transactions actually processed: 33/100
number of transactions skipped: 67 (67.000 %)
number of transactions above the 1.0 ms latency limit: 33 (33 of 33, 100.000 %)

(My proposed change is in the last line.)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: feature request: consume asynchronous notification via a function
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager