Horton

Re: Reducing the runtime of the core regression tests

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-12T16:48:06Z
Lists: pgsql-hackers 
On Fri, Apr 12, 2019 at 9:31 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Done.  Do you have a preferred spot where the counts were wrong?

Not really, but I can give you an example.

Line counts for each of the two "break" statements within
_bt_keep_natts_fast() are exactly the same. I don't think that this
because we actually hit each break exactly the same number of times
(90,236 times). I think that we see this because the same instruction
is associated with both break statements in the loop. All of the
examples I've noticed are a bit like that. Not a huge problem, but
less useful than the alternative.

-- 
Peter Geoghegan

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.