Horton

Re: Reducing the runtime of the core regression tests

David Rowley <david.rowley@2ndquadrant.com>

View thread View on postgr.es
From: David Rowley <david.rowley@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-11T00:27:20Z
Lists: pgsql-hackers 
On Thu, 11 Apr 2019 at 10:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In no particular order, here's what I did:

I was surprised to see nothing mentioned about attempting to roughly
sort the test order in each parallel group according to their runtime.
Shorter running test coming last should reduce the chances of one
process doing its last test when all other processes are already done
and sitting idle.   Of course, this won't be consistent over all
hardware, but maybe it could be done as an average time for each test
over the entire buildfarm.

> 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.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Re-order some regression test scripts for more parallelism.

  2. Speed up sort-order-comparison tests in create_index_spgist.

  3. Split up a couple of long-running regression test scripts.

  4. Move plpgsql error-trapping tests to a new module-specific test file.

  5. Remove duplicative polygon SP-GiST sequencing test.

  6. Remove redundant and ineffective test for btree insertion fast path.

  7. Adjustments to the btree fastpath optimization.

  8. Increase timeout in statement_timeout test from 1 second to 2 seconds.