Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2)
От | Dmitry Dolgov |
---|---|
Тема | Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2) |
Дата | |
Msg-id | te7bkg5vcryggq2bkt3nfde3tqphu35e5oyzzh3rwn3gg34jrs@vdo674od6cnu обсуждение исходный текст |
Ответ на | Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2) (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2)
|
Список | pgsql-hackers |
> 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+postgres@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.
В списке pgsql-hackers по дате отправления: