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

On Mon, Dec 30, 2019 at 10:57 AM Anastasia Lubennikova
<a(dot)lubennikova(at)postgrespro(dot)ru> wrote:
> 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.

It seems like the simplest thing might be to forget about the 'char'
column and just have a support function which can be used to assess
whether a given opclass's notion of equality is bitwise. If equality
is always bitwise, the function can always return true. If it's
sometimes bitwise, it can return true or false as appropriate. If it's
never bitwise, then it can either always return false or the support
function can be omitted altogether (so that the safe value is the
default).

I don't think you're going to save very much by avoiding an indirect
function call in the "always" case. It doesn't really seem worth the
complexity of making that a special case.

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