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

From Tom Lane
Subject Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence
Date
Msg-id 2871.1566766573@sss.pgh.pa.us
Whole thread Raw
In response to Building infrastructure for B-Tree deduplication that recognizes whenopclass equality is also equivalence  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence  (Peter Geoghegan <pg@bowt.ie>)
Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> We don't need to be able to assume that binary equality is exactly the
> same thing as opclass equality at the level of individual tuples. We
> only need to be able to assume that the user cannot observe any
> differences when they are shown output for two datums that are
> opclass-equal for any opclass that supports deduplication (i.e. cases
> like the numeric_ops case just won't work, so we shouldn't event try).

Hmm, so that would exclude the optimization for numeric, float4/float8,
and nondeterministic text collations.  Anything else?

I agree that teaching opclasses to say whether this is okay is a
reasonable approach.

> Consumers of this new infrastructure probably won't be limited to the
> deduplication feature;

Indeed, we run up against this sort of thing all the time in, eg, planner
optimizations.  I think some sort of "equality is precise" indicator
would be really useful for a lot of things.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: mingw32 floating point diff
Next
From: Peter Geoghegan
Date:
Subject: Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence