Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL
Дата
Msg-id 87wtq7q8zk.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL
Список pgsql-performance
Tom Lane <tgl@sss.pgh.pa.us> writes:

> > What if the hash index stored *only* the hash code? That could be useful for
> > indexing large datatypes that would otherwise create large indexes.
>
> Hmm, that could be a thought.

Hm, if you go this route of having hash indexes store tuples ordered by hash
code and storing the hash code in the index, then it seems hash indexes become
just a macro for a btree index of HASH(index columns).

I'm not saying that to criticize this plan. In fact I think that captures most
(though not all) of what a hash index should be.

It would be pretty useful. In fact if it isn't how hash indexes are
implemented then it might be useful to provide a user visible hash(ROW)
function that allows creating such indexes as functional indexes. Though
hiding it would make the SQL simpler.

--
greg

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

Предыдущее
От: PFC
Дата:
Сообщение: Re: Partitioning / Clustering
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Partitioning / Clustering