Joshua D. Drake wrote:
> That said would it be possible to make this index an extension (like rum?).
> Assuming of course we can get any required infrastructure changes done in a
> general way.
Well, the patch I currently have creates a separate index AM called
"ibtree" which is an indirect btree that internally calls the regular
btree code -- pretty much what you propose. I think it can work that
way, but it's not as efficient as it can be done if the feature is
incorporated into core. There are things like obtaining the primary key
value from the indexed tuple: in my extension I simply do "heap_fetch"
to obtain the heap tuple, then heap_getattr() to obtain the values from
the primary key columns. This works, but if instead the executor passes
the primary key values as parameters, I can save both those steps, which
are slow.
Now if we do incorporate the infrastructure changes in core in a general
way, which is what I am proposing, then the in-core provided btree AM
can do indirect indexes without any further extension. The same
infrastructure changes can later provide support for GIN indexes.
> I do think the feature has merit.
Thanks.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
