On Wed, Apr 10, 2019 at 4:19 PM Tom Lane <tgl@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
