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-11T04:54:09Z
Lists: pgsql-hackers 
On Thu, 11 Apr 2019 at 16:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <david.rowley@2ndquadrant.com> 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.

I probably have looked closer to how that is handled. If they're all
launched at once then there's no point to what I mentioned. Please
disregard.

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