From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Reducing the runtime of the core regression tests
In-reply-to: <20190410224830.wrshpdlt3ktjrava@alap3.anarazel.de>
References: <735.1554935715@sss.pgh.pa.us>
 <20190410224830.wrshpdlt3ktjrava@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Wed, 10 Apr 2019 15:48:30 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14130.1554936865.1@sss.pgh.pa.us>
Date: Wed, 10 Apr 2019 18:54:25 -0400
Message-ID: <14131.1554936865@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2019-04-10 18:35:15 -0400, Tom Lane wrote:
>> ... What I did instead was to shove
>> that test case and some related ones into a new plpgsql test file,
>> src/pl/plpgsql/src/sql/plpgsql_trap.sql, so that it's not part of the
>> core regression tests at all.  (We've talked before about moving
>> chunks of plpgsql.sql into the plpgsql module, so this is sort of a
>> down payment on that.)  Now, if you think about the time to do
>> check-world rather than just the core regression tests, this isn't
>> obviously a win, and in fact it might be a loss because the plpgsql
>> tests run serially not in parallel with anything else.

> Hm, can't we "just" parallelize the plpgsql schedule instead?

If somebody wants to work on that, I won't stand in the way, but
it seems like material for a different patch.

>> Thoughts?  Anyone object to making these sorts of changes
>> post-feature-freeze?

> Hm. There's some advantage to doing so, because it won't break any large
> pending changes.  But it's also possible that it'll destabilize the
> buildfarm some.  In personal capacity I'm like +0.5.

My thought was that there is (hopefully) going to be a lot of testing
going on over the next few months, so making that faster would be
a useful activity.

			regards, tom lane