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 1hERZO-00024J-NQ for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Apr 2019 04:44:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hERZN-0006X4-2A for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Apr 2019 04:44:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hERZM-0006Wx-N7 for pgsql-hackers@lists.postgresql.org; Thu, 11 Apr 2019 04:44:12 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hERZG-00072a-3K for pgsql-hackers@lists.postgresql.org; Thu, 11 Apr 2019 04:44: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 x3B4i2kO012466; Thu, 11 Apr 2019 00:44:02 -0400 From: Tom Lane To: David Rowley cc: PostgreSQL Hackers Subject: Re: Reducing the runtime of the core regression tests In-reply-to: References: <735.1554935715@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Thu, 11 Apr 2019 12:27:20 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12464.1554957842.1@sss.pgh.pa.us> Date: Thu, 11 Apr 2019 00:44:02 -0400 Message-ID: <12465.1554957842@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk David Rowley writes: > I was surprised to see nothing mentioned about attempting to roughly > sort the test order in each parallel group according to their runtime. I'm confused about what you have in mind here? I'm pretty sure pg_regress launches all the scripts in a group at the same time, so that just rearranging the order they're listed in on the schedule line shouldn't make any noticeable difference. If you meant changing the order of operations within each script, I don't really want to go there. It'd require careful per-script analysis, and to the extent that the existing tests have some meaningful ordering (admittedly, many don't), we'd lose that. >> Thoughts? Anyone object to making these sorts of changes >> post-feature-freeze? > I think it's a good time to do this sort of thing. It should be > easier to differentiate tests destabilising due to this change out > from the noise of other changes that are going in.... since currently, > the rate of those other changes should not be very high. Doing it any > later in the freeze does not seem better since we might discover some > things that need to be fixed due to this. Yeah. I wouldn't propose pushing this in shortly before beta, but if we do it now then we've probably got a month to sort out any problems that may appear. regards, tom lane