PostgreSQL 13 B-Trees will be able to use deduplication, which I committed today. It often make indexes far smaller. Also helps VACUUM with controlling index bloat (even in unique indexes). I wrote some documentations on the internals, for advanced users: postgresql.org/docs/devel/btr
Conversation
This Tweet was deleted by the Tweet author. Learn more
Thanks! I don't know much about MLS. Still, I can't imagine a way in which deduplication would make MLS any harder. The deduplication design is fundamentally based on the idea that we never change the logical/observable contents of the index. It's entirely a storage level thing.
1
Is there a better DB than PostgreSQL? I so try to find something else but keep coming back. Not complaining, just grateful we have it.
1
1
5
Replying to
Is this going to enable automatically for indexes after a pg_upgrade (lazily, obviously) , or is a reindex going to be required?
1
Replying to
REINDEX required. It could work with v12 indexes lazily if pg_upgrade were taught to set the metapage field automatically, but I didn't bother with that. Even if I did, it wouldn't immediately shrink the index after upgrade.
1
2
Show replies
Replying to
This is nice. I know of it via the name RID-list.
* step 1 - support this for index entries
* step 2- add lightweight compression for RID-lists
* step 3 - support efficient and/or/count on compressed RID-list during query execution
1
1
3
Replying to
The overhead is low enough for the deduplication feature to work well with OLTP or mixed workloads. It will probably remain enabled by default in the next stable Postgres release. Lazy approach has significant upsides.
1
4
Show replies