Re: Hash index

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Hash index
Дата
Msg-id 24115.1125430346@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Hash index  (Scott Marlowe <smarlowe@g2switchworks.com>)
Ответы Re: Hash index  ("Jim C. Nasby" <jnasby@pervasive.com>)
Re: Hash index  (Scott Marlowe <smarlowe@g2switchworks.com>)
Список pgsql-admin
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

В списке pgsql-admin по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: Hash index
Следующее
От: David Durham
Дата:
Сообщение: Re: First mail after registration