On Thu, Apr 27, 2023 at 11:17 AM Peter Geoghegan <pg@bowt.ie> wrote:
> I'm asking this (at least in part) because it affects the answer. Lots
> of stuff that GIN does that seems like it would be particularly tricky
> to integrate with a system catalog is non-essential. It could be (and
> sometimes is) selectively disabled. Whereas B-Tree indexes don't
> really have any optional features (you can disable deduplication
> selectively, but I believe that approximately nobody ever found it
> useful to do so).
Actually, you *can't* disable deduplication against a system catalog
index in practice, due to a limitation with storage parameters. That's
why deduplication was disabled against system catalogs until Postgres
15.
That limitation would be much harder to ignore with GIN indexes.
B-Tree/nbtree deduplication is more or less optimized for being
enabled by default. It has most of the upside of posting lists, with
very few downsides. For example, you can sometimes get a lot more
space savings with Posting list compression (very low cardinality
indexes can be as much as 10x smaller), but that's not really
compatible with the design of nbtree deduplication.
--
Peter Geoghegan