GiST a second class citizen?
The PostGIS project has been making use of GiST for about a year now and
(thanks to the excellent work of Oleg and Teodor) have found it to be a
most excellent indexing system.
We are about to apply for some government R&D funding, and one of our
potential subprojects is creating GiST bindings for all the standard SQL
PostgreSQL types. Why? Well, because our spatial indexes are GiST,
providing bindings for the standard types allows us to do multi-key
indexes which combine spatial and non-spatial data. That would be pretty
unique in the DMBS world as it stands right now.
So far, GiST is integrated into the main tree, but all the bindings seem
to be kept outside, in contrib (ltree, btree, rtree). If there were a
complete set of GiST b-tree bindings available for the builtin types,
where would/should they reside? Would I be completely out-to-lunch if I
suggested that the GiST bindings might even replace the standard ones?
The ability to multikey indexes of wierd-and-crazy-types with
normal-boring-types seems like a halmark of a Real Live
Object-Relational DBMS.
Thoughts?
Paul
Paul Ramsey <pramsey@refractions.net> writes:
So far, GiST is integrated into the main tree, but all the bindings seem
to be kept outside, in contrib (ltree, btree, rtree).
This is a historical artifact. As GiST comes more up-to-speed, the
operator classes for it should become mainstream.
Would I be completely out-to-lunch if I suggested that the GiST
bindings might even replace the standard ones?
Yes. There is no "replacement" involved here, because opclasses for
different index types are quite independent.
(Perhaps what you are really suggesting is that GiST should become the
default index type instead of btree --- to which I can only reply that
it's got a *long* way to go before that would be considered for an
instant...)
regards, tom lane