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

On Sat, Feb 8, 2020 at 6:50 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> My working assumption is that I only need to care about
> opclass-declared input data types (pg_opclass.opcintype), plus the
> corresponding collations -- the former can be used to lookup an
> appropriate pg_amproc entry (i.e. B-Tree support function 4), while
> the latter are passed to the support function to get an answer about
> whether or not it's okay to use deduplication. This approach seems to
> be good enough as far as the deduplication project's needs are
> concerned. However, I think that I probably need to take a broader
> view of the problem than that. Any guidance would be much appreciated.

v33 of the deduplication patch series was just posted. It included
this infrastructure in a separate patch, which isn't that big on its
own. See:

https://www.postgresql.org/message-id/CAH2-WzmQGYDDoAETGhpGtJQRv_uFHMjvQZ6JdLV-sxGoCgLBNg%40mail.gmail.com

Expert review of the opclass infrastructure still seems like a good
idea. I'm sure that it does everything that the deduplication feature
will ever need, but I'm a little concerned about painting myself into
a corner as far as other things that use the API are concerned. In
particular, I hope that I haven't failed to anticipate a requirement
that the planner has for the new API.

Thanks
--
Peter Geoghegan