Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hEd07-00062z-EI for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Apr 2019 16:56:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hEd06-0005l6-22 for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Apr 2019 16:56:34 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1hEcyl-0007hW-VH for pgsql-hackers@lists.postgresql.org; Thu, 11 Apr 2019 16:55:12 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hEcyj-00029q-GJ for pgsql-hackers@lists.postgresql.org; Thu, 11 Apr 2019 16:55:11 +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 x3BGt4wv013133; Thu, 11 Apr 2019 12:55:05 -0400 From: Tom Lane To: Peter Geoghegan cc: PostgreSQL Hackers Subject: Re: Reducing the runtime of the core regression tests In-reply-to: References: <735.1554935715@sss.pgh.pa.us> <32387.1554938378@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Wed, 10 Apr 2019 17:08:55 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13131.1555001704.1@sss.pgh.pa.us> Date: Thu, 11 Apr 2019 12:55:04 -0400 Message-ID: <13132.1555001704@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Geoghegan writes: > On Wed, Apr 10, 2019 at 4:56 PM Peter Geoghegan wrote: >> The original fastpath tests don't seem particularly effective to me, >> even without the oversight I mentioned. I suggest that you remove >> them, since the minimal btree_index.sql fast path test is sufficient. > To be clear: I propose that you remove the tests entirely, and we > leave it at that. I don't intend to follow up with my own patch > because I don't think that there is anything in the original test case > that is worth salvaging. I checked into this by dint of comparing "make coverage" output for "make check" runs with and without indexing.sql's fastpath tests. There were some differences that seem mostly to be down to whether or not autovacuum hit particular code paths during the test run. In total, I found 29 lines that were hit in the first test but not in the second ... and 141 lines that were hit in the second test but not the first. So I concur that indexing.sql's fastpath test isn't adding anything useful coverage-wise, and will just nuke it. (It'd be interesting perhaps to check whether the results shown by coverage.postgresql.org are similarly unstable. They might be less so, since I believe those are taken over the whole check-world suite not just the core regression tests.) regards, tom lane