Thread: Decouple operator classes from index access methods

I think we can benefit from higher level operator classes which can
support multiple index implementations.  This is achievable by
introducing another type of access method.  Here is my idea in SQL:

CREATE ACCESS METHOD ordering
TYPE INTERFACE HANDLER ordering_ifam_handler;

CREATE ACCESS METHOD btree
TYPE INDEX HANDLER bthandler
IMPLEMENTS (ordering);

CREATE OPERATOR CLASS btree_int_ops
FOR TYPE int USING ordering AS
FUNCTION 1 btint4cmp(int, int),
FUNCTION 3 =(int, int);

This can make it easier to develop both new index access methods and
data types.  The extensions can provide them without depending on each
other.

The initial implementation is attached.  I wrote it only to ask for
feedback.  I am happy to work on the missing pieces if the community
supports the idea.

I suggest the initial version to come with 2 new access methods in the
new type: hashing and ordering.  We can use those in the functions
that are currently searching for the hash and btree operator classes.

Later, I want to work on developing another access method for
containment.  It can support high level operator classes with only SQL
callable functions.  GiST, SP-GiST, and BRIN can implement this.  We
can allow the new implementations together with the existing ones.

Emre Hasegeli <emre@hasegeli.com> writes:
> I think we can benefit from higher level operator classes which can
> support multiple index implementations.  This is achievable by
> introducing another type of access method.

I do not really understand what the point of that is?

To the extent that operator classes have any meaning at all apart
from the associated index AMs, ISTM it's that they embody specific
well-known semantics, as btree and hash opclasses do for sorting
and hashing respectively.  I'm not clear on what a multi-AM
opclass notion would do for us.

> I suggest the initial version to come with 2 new access methods in the
> new type: hashing and ordering.  We can use those in the functions
> that are currently searching for the hash and btree operator classes.

Again, exactly what does that buy us, other than more complication
and overhead?

I can see some value perhaps in letting other opclasses refer to
btree and hash opclasses rather than duplicating their entries.
But that doesn't seem to be what you're proposing here.

            regards, tom lane

> I can see some value perhaps in letting other opclasses refer to
> btree and hash opclasses rather than duplicating their entries.
> But that doesn't seem to be what you're proposing here.

That's what I am proposing.  My idea is to change the current btree
and hash opclasses to be under the new proposed access methods so
btree, hash, and any other index access method can refer to them.

On Tue, Jun 22, 2021 at 8:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I suggest the initial version to come with 2 new access methods in the
> > new type: hashing and ordering.  We can use those in the functions
> > that are currently searching for the hash and btree operator classes.
>
> Again, exactly what does that buy us, other than more complication
> and overhead?
>
> I can see some value perhaps in letting other opclasses refer to
> btree and hash opclasses rather than duplicating their entries.
> But that doesn't seem to be what you're proposing here.

In future we could have, for instance, LSM or in-memory B-tree or
other index AM, which could use existing B-tree or hash opclasses.

But even now, we could use this decoupling to get rid of ugly
btree_gist and btree_gin.  And also solve the extensibility problem
here.  If an extension provides datatype with B-tree opclass, we
currently can't directly use it with GiST and GIN.  So, in order to
provide B-tree-like indexing for GiST and GIN, an extension needs to
explicitly define GiST and GIN B-tree-like opclasses.

From my point of view, we can consider a decoupling patch if it will
come with an ability to use B-tree opclasses directly in GiST and GIN.

------
Regards,
Alexander Korotkov

> In future we could have, for instance, LSM or in-memory B-tree or
> other index AM, which could use existing B-tree or hash opclasses.

This would be easily possible with my patch:

CREATE ACCESS METHOD inmemorybtree
TYPE INDEX HANDLER imbthandler
IMPLEMENTS (ordering);

> But even now, we could use this decoupling to get rid of ugly
> btree_gist and btree_gin.  And also solve the extensibility problem
> here.  If an extension provides datatype with B-tree opclass, we
> currently can't directly use it with GiST and GIN.  So, in order to
> provide B-tree-like indexing for GiST and GIN, an extension needs to
> explicitly define GiST and GIN B-tree-like opclasses.

This would also be possible if we move btree_gist and btree_gin
support functions inside gist and gin access methods.  The access
method support functions get the operator family.  They can find which
access method this operator family belongs to, and call the
appropriate functions if it is "ordering".

On Fri, Jun 25, 2021 at 12:18 PM Emre Hasegeli <emre@hasegeli.com> wrote:
> > In future we could have, for instance, LSM or in-memory B-tree or
> > other index AM, which could use existing B-tree or hash opclasses.
>
> This would be easily possible with my patch:
>
> CREATE ACCESS METHOD inmemorybtree
> TYPE INDEX HANDLER imbthandler
> IMPLEMENTS (ordering);
>
> > But even now, we could use this decoupling to get rid of ugly
> > btree_gist and btree_gin.  And also solve the extensibility problem
> > here.  If an extension provides datatype with B-tree opclass, we
> > currently can't directly use it with GiST and GIN.  So, in order to
> > provide B-tree-like indexing for GiST and GIN, an extension needs to
> > explicitly define GiST and GIN B-tree-like opclasses.
>
> This would also be possible if we move btree_gist and btree_gin
> support functions inside gist and gin access methods.  The access
> method support functions get the operator family.  They can find which
> access method this operator family belongs to, and call the
> appropriate functions if it is "ordering".

Yes, that's it.  That's quite an amount of work, but I think this
would be a great illustration of the advantages of this decoupling.

------
Regards,
Alexander Korotkov