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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL
Дата
Msg-id 9871.1115733198@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL  (Greg Stark <gsstark@mit.edu>)
Ответы Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL  (Greg Stark <gsstark@mit.edu>)
Список pgsql-performance
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I think that efficient implementation of this would require explicitly
>> storing the hash code for each index entry,

> It seems that means doubling the size of the hash index. That's a pretty big
> i/o to cpu tradeoff.

Hardly.  The minimum possible size of a hash entry today is 8 bytes
header plus 4 bytes datum, plus there's a 4-byte line pointer to factor
in.  So under the most pessimistic assumptions, storing the hash code
would add 25% to the size.  (On MAXALIGN=8 hardware, it might cost you
nothing at all.)

> 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.

            regards, tom lane

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

Предыдущее
От: Matt Olson
Дата:
Сообщение: Prefetch
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Prefetch