Обсуждение: 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