Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence - Mailing list pgsql-hackers

From Anastasia Lubennikova
Subject Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence
Date
Msg-id d8d75df3-4c41-ce13-6174-5f14b35e6f5a@postgrespro.ru
Whole thread Raw
In response to Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence
List pgsql-hackers
29.12.2019 2:56, Robert Haas wrote:
> On Tue, Dec 24, 2019 at 7:29 AM Anastasia Lubennikova
> <a.lubennikova@postgrespro.ru> wrote:
>> We can make this 'opcisbitwise' parameter enum (or char) instead of
>> boolean to mark
>> "always bitwise", "never bitwise" and "maybe bitwise". Though, I doubt
>> if it will be helpful in any real use case.
> What would be the difference between "never bitwise" and "maybe
> bitwise" in that scheme?

In this design "maybe" category reflects the need for an extra recheck.

For example, float and numeric types are "never bitwise equal", while array,
text, and other container types are "maybe bitwise equal". An array of 
integers
or text with C collation can be treated as bitwise equal attributes, and it
would be too harsh to restrict them from deduplication.

What bothers me is that this option will unlikely be helpful on its own 
and we
should also provide some kind of recheck function along with opclass, which
complicates this idea even further and doesn't seem very clear.

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: comment regarding double timestamps; and, infinite timestampsand NaN
Next
From: Philippe BEAUDOIN
Date:
Subject: Re: proposal: schema variables