> On Tue, Aug 13, 2024 at 02:39:10PM GMT, Peter Geoghegan wrote: > On Tue, Aug 6, 2024 at 5:42 PM Matthias van de Meent > <boekewurm+postg...@gmail.com> wrote: > > Attached is version 16 now. > > I ran this with my old land registry benchmark, used for validating > the space utilization impact of nbtree deduplication (among other > things). This isn't obviously the best benchmark for this sort of > thing, but I seem to recall that you'd used it yourself at some point. > To validate work in this area, likely including this patch. So I > decided to start there. > > To be clear, this test involves bulk loading of an unlogged table (the > land registry table). The following composite index is created on the > table before we insert any rows, so most of the cycles here are in > index maintenance including _bt_search descents: > > CREATE INDEX composite ON land2 USING btree (county COLLATE "C", city > COLLATE "C", locality COLLATE "C"); > > I wasn't able to see much of an improvement with this patch applied. > It went from ~00:51.598 to ~00:51.053. That's a little disappointing, > given that this is supposed to be a sympathetic case for the patch. > Can you suggest something else? (Granted, I understand that this patch > has some complicated relationship with other patches of yours, which I > don't understand currently.)
Under the danger of showing my ignorance, what is the definition of land registry benchmark? I think it would be useful if others could reproduce the results as well, especially if they're somewhat surprising. At the same time I would like to note, that dynamic prefix truncation can be useful not only on realistic data, but in some weird-but-useful cases, e.g. for partitioned B-Tree with an artificial leading key separating partitions. It's a hypothetical case, which can't justify a feature of course, but makes it worth investigating.
