Hi Bruce,
On Mon, May 4, 2020 at 8:16 PM Bruce Momjian <bruce@momjian.us> wrote:
> I have committed the first draft of the PG 13 release notes. You can
> see them here:
>
> https://momjian.us/pgsql_docs/release-13.html
I see that you have an entry for the deduplication feature:
"More efficiently store duplicates in btree indexes (Anastasia
Lubennikova, Peter Geoghegan)"
I would like to provide some input on this. Fortunately it's much
easier to explain than the B-Tree work that went into Postgres 12. I
think that you should point out that deduplication works by storing
the duplicates in the obvious way: Only storing the key once per
distinct value (or once per distinct combination of values in the case
of multi-column indexes), followed by an array of TIDs (i.e. a posting
list). Each TID points to a separate row in the table.
It won't be uncommon for this to make indexes as much as 3x smaller
(it depends on a number of different factors that you can probably
guess). I wrote a summary of how it works for power users in the
B-Tree documentation chapter, which you might want to link to in the
release notes:
https://www.postgresql.org/docs/devel/btree-implementation.html#BTREE-DEDUPLICATION
Users that pg_upgrade will have to REINDEX to actually use the
feature, regardless of which version they've upgraded from. There are
also some limited caveats about the data types that can use
deduplication, and stuff like that -- see the documentation section I
linked to.
Finally, you might want to note that the feature is enabled by
default, and can be disabled by setting the "deduplicate_items" index
storage option to "off". (We have yet to make a final decision on
whether the feature should be enabled before the first stable release
of Postgres 13, though -- I have an open item for that.)
--
Peter Geoghegan