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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-11T17:02:02Z
Lists: pgsql-hackers 
On Thu, Apr 11, 2019 at 9:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So I concur that indexing.sql's fastpath test
> isn't adding anything useful coverage-wise, and will just nuke it.

Good.

> (It'd be interesting perhaps to check whether the results shown
> by coverage.postgresql.org are similarly unstable.  They might be
> less so, since I believe those are taken over the whole check-world
> suite not just the core regression tests.)

I'm almost certain that they're at least slightly unstable. I mostly
find the report useful because it shows whether or not something gets
hit at all. I don't trust it to be very accurate.

I've noticed that the coverage reported on coverage.postgresql.org
sometimes looks contradictory, which can happen due to compiler
optimizations. I wonder if that could be addressed in some way,
because I find the site to be a useful resource. I would at least like
to know the settings used by its builds.

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