On Fri, Jun 25, 2021 at 12:18 PM Emre Hasegeli 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 HA
> 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
On Tue, Jun 22, 2021 at 8:06 PM Tom Lane 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 t
> 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
Emre Hasegeli 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
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 b
