Re: Deleting older versions in unique indexes to avoid page splits
От | Peter Geoghegan |
---|---|
Тема | Re: Deleting older versions in unique indexes to avoid page splits |
Дата | |
Msg-id | CAH2-WzkwprjUUsADejaOtWje2SyQ_fPQsdWmM_0SS5BKkGdhWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Deleting older versions in unique indexes to avoid page splits (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Deleting older versions in unique indexes to avoid page splits
Re: Deleting older versions in unique indexes to avoid page splits Re: Deleting older versions in unique indexes to avoid page splits |
Список | pgsql-hackers |
On Wed, Dec 9, 2020 at 5:12 PM Peter Geoghegan <pg@bowt.ie> wrote: > Attached is v11, which cleans everything up around the tableam > interface. There are only two patches in v11, since the tableam > refactoring made it impossible to split the second patch into a heapam > patch and nbtree patch (there is no reduction in functionality > compared to v10). Attached is v12, which fixed bitrot against the master branch. This version has significant comment and documentation revisions. It is functionally equivalent to v11, though. I intend to commit the patch in the next couple of weeks. While it certainly would be nice to get a more thorough review, I don't feel that it is strictly necessary. The patch provides very significant benefits with certain workloads that have traditionally been considered an Achilles' heel for Postgres. Even zheap doesn't provide a solution to these problems. The only thing that I can think of that might reasonably be considered in competition with this design is WARM, which hasn't been under active development since 2017 (I assume that it has been abandoned by those involved). I should also point out that the design doesn't change the on-disk format in any way, and so doesn't commit us to supporting something that might become onerous in the event of somebody else finding a better way to address at least some of the same problems. -- Peter Geoghegan
Вложения
В списке pgsql-hackers по дате отправления: