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

01.10.2019 8:41, Antonin Houska wrote:
> Anastasia Lubennikova <a.lubennikova@postgrespro.ru> wrote:
>
>> The patch implementing new opclass option is attached.
>>
>> It adds new attribute pg_opclass.opcisbitwise, which is set to true if opclass
>> equality is the same as binary equality.
>> By default it is true.
> I think the default value should be false and we should only set it to true
> for individual opclasses which do meet the bitwise equality requirement. Also
> extension authors should explicitly state that their data types are bitwise
> equal. Otherwise the existing opclasses, when created via pg_dump ->
> pg_restore, can be used by the system incorrectly.

Thank you for the feedback.

At first I implemented bitwise as default, because it is more common .
Though, I agree that it's essential to avoid false positives here.
The new version of the patch is attached. I also updated pg_dump.

A few more open questions:
1) How to handle contrib modules that create new opclasses?
Since default is 'not bitwise' it means that various operator classes 
created in extensions
such as bloom, btree_gin and others, won't be able to take advantage of 
various optimizations
that require the opclass to be BITWISE.

'v2-Opclass-bitwise-equality-0002' patch simply adds BITWISE keyword 
where necessary.

2) Whether we should provide ALTER OPERATOR CLASS SET BITWISE syntax?

3) Current patch modifies regression test so that it checks CREATE 
OPCLASS BITWISE syntax.
Is there anything else worth testing? As I see it, this patch is just 
about infrastructure changes,
and more specific tests will be added by features that will implement 
further optimizations.

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