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
