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
|
Список | 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 по дате отправления: