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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
