On Wed, Apr 10, 2019 at 4:19 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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. > > Should I leave out the part of my patch that creates index_fastpath.sql? > If we're going to end up removing that version of the test, there's no > point in churning the related lines beforehand.
The suffix truncation stuff made it tricky to force a B-Tree to be tall without also consisting of many blocks. Simply using large, random key values in suffix attributes didn't work anymore. The solution I came up with for the new fastpath test that made it into btree_index.sql was to have redundancy in leading keys, while avoiding TOAST compression by using plain storage in the table/index. > One way or the other I want to get that test out of where it is, > because indexing.sql is currently the slowest test in its group. > But if you prefer to make btree_index run a bit longer rather than > inventing a new test script, that's no problem from where I stand. The original fastpath tests don't seem particularly effective to me, even without the oversight I mentioned. I suggest that you remove them, since the minimal btree_index.sql fast path test is sufficient. If there ever was a problem in this area, then amcheck would certainly detect it -- there is precisely one place for every tuple on v4 indexes. The original fastpath tests won't tickle the implementation in any interesting way in my opinion. -- Peter Geoghegan