Re: Reducing the runtime of the core regression tests
Peter Geoghegan <pg@bowt.ie>
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-10T23:12:43Z
Lists: pgsql-hackers
On Wed, Apr 10, 2019 at 3:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > I finally got some time to pursue that, and attached is a proposed patch > that moves some tests around and slightly adjusts some other ones. > To cut to the chase: on my workstation, this cuts the time for > "make installcheck-parallel" from 21.9 sec to 13.9 sec, or almost 40%. > I think that's a worthwhile improvement, considering how often all of us > run those tests. Great! > * create_index.sql ran much longer than other tests in its parallel > group, so I split out the SP-GiST-related tests into a new file > create_index_spgist.sql, and moved the delete_test_table test case > to btree_index.sql. Putting the delete_test_table test case in btree_index.sql make perfect sense. > * Likewise, I split up indexing.sql by moving the "fastpath" test into > a new file index_fastpath.sql. I just noticed that the "fastpath" test actually fails to test the fastpath optimization -- the coverage we do have comes from another test in btree_index.sql, that I wrote back in December. While I did make a point of ensuring that we had test coverage for the nbtree fastpath optimization that went into Postgres 11, I also didn't consider the original fastpath test. I assumed that there were no tests to begin with, because gcov showed me that there was no test coverage back in December. What happened here was that commit 074251db limited the fastpath to only be applied to B-Trees with at least 3 levels. While the original fastpath optimization tests actually tested the fastpath optimization when it first went in in March 2018, that only lasted a few weeks, since 074251db didn't adjust the test to still be effective. I'll come up with a patch to deal with this situation, by consolidating the old and new tests in some way. I don't think that your work needs to block on that, though. > Thoughts? Anyone object to making these sorts of changes > post-feature-freeze? IMV there should be no problem with pushing ahead with this after feature freeze. -- Peter Geoghegan
Commits
-
Re-order some regression test scripts for more parallelism.
- 798070ec058f 12.0 landed
-
Speed up sort-order-comparison tests in create_index_spgist.
- 5874c7055702 12.0 landed
-
Split up a couple of long-running regression test scripts.
- 385d396b807b 12.0 landed
-
Move plpgsql error-trapping tests to a new module-specific test file.
- 6726d8d476b4 12.0 landed
-
Remove duplicative polygon SP-GiST sequencing test.
- 4aaa3b5cf1c3 12.0 landed
-
Remove redundant and ineffective test for btree insertion fast path.
- f72d9a5e7dda 12.0 landed
-
Adjustments to the btree fastpath optimization.
- 074251db6740 11.0 cited
-
Increase timeout in statement_timeout test from 1 second to 2 seconds.
- f1e671a0b485 8.2.0 cited