Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHF9v-0000oT-Ue for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Nov 2017 20:28:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHF9v-00011M-GM for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Nov 2017 20:28:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eHF9v-00011C-B4 for pgsql-hackers@lists.postgresql.org; Tue, 21 Nov 2017 20:28:43 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eHF9r-000787-Rx for pgsql-hackers@postgresql.org; Tue, 21 Nov 2017 20:28:42 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vALKSYBn019484; Tue, 21 Nov 2017 15:28:34 -0500 From: Tom Lane To: Robert Haas cc: Fabien COELHO , Steve Singer , PostgreSQL Developers Subject: Re: [HACKERS] pgbench regression test failure In-reply-to: References: <26654.1505232433@sss.pgh.pa.us> <20171112024739.23750.54311.pgcf@coridan.postgresql.org> <28977.1511125910@sss.pgh.pa.us> <19670.1511203257@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 21 Nov 2017 15:21:56 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19482.1511296114.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Nov 2017 15:28:34 -0500 Message-ID: <19483.1511296114@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Mon, Nov 20, 2017 at 1:40 PM, Tom Lane 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.) Seems like a good idea, but the way you've written it is inconsistent with the "n/m" notation used just above. I'd suggest ... latency limit: 33 (33/33, 100.000 %) or just ... latency limit: 33/33 (100.000 %) regards, tom lane