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