Re: Enabling B-Tree deduplication by default - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Enabling B-Tree deduplication by default
Date
Msg-id CA+TgmobaQwYtweryBV4Dt7jZ9+tqqoz7+NGDwN-FGt86RQA3Qg@mail.gmail.com
Whole thread Raw
In response to Enabling B-Tree deduplication by default  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Enabling B-Tree deduplication by default  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Wed, Jan 15, 2020 at 6:38 PM Peter Geoghegan <pg@bowt.ie> wrote:
> There are some outstanding questions about how B-Tree deduplication
> [1] should be configured, and whether or not it should be enabled by
> default. I'm starting this new thread in the hopes of generating
> discussion on these high level questions.

It seems like the issue here is that you're pretty confident that
deduplication will be a win for unique indexes, but not so confident
that this will be true for non-unique indexes. I don't know that I
understand why.

It does seem odd to me to treat them differently, but it's possible
that this is a reflection of my own lack of understanding. What do
other database systems do?

I wonder whether we could avoid the downside of having only one
LP_DEAD bit per line pointer by having a bit per TID within the
compressed tuples themselves. I assume you already thought about that,
though.

What are the characteristics of this system if you have an index that
is not declared as UNIQUE but actually happens to be UNIQUE?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: making the backend's json parser work in frontend code
Next
From: David Steele
Date:
Subject: Re: making the backend's json parser work in frontend code