Scott Marlowe <smarlowe@xxxxxxxxxxxxxxxxx> 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
