Scott Marlowe <smarlowe@g2switchworks.com> writes:
> Personally, I think that when one creates a non-btree index, one should
> get a warning saying that non-btree indexes are not necessarily
> transactionally safe in the event of a crash.
As of 8.1, GIST indexes are WAL-logged, so that would be inappropriate
anyway.
What I foresee happening (soon, 8.2 maybe) is that rtree will go away
completely; there isn't anything it can do that GIST can't do as well or
better, so there's no point in expending maintenance resources on it.
We're really only leaving it there for 8.1 because there's so much new,
as-yet-poorly-tested code involved in the GIST replacement opclasses.
That leaves hash. I'm hoping someone will step up and do WAL logging
for hash in the near future. Unlike rtree, I'm not expecting that we
might get rid of hash indexes. Even if the performance problems never
get fixed, we use hash index opclasses to manage datatype-specific
hashing for hash joins, hash aggregation, etc, so if we removed hash
indexes we'd need to find some other representation for all that.
Anyway, that's my two cents on the development roadmap for indexes.
regards, tom lane
