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