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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Neil Conway <neilc(at)samurai(dot)com>, "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, Christopher Petrilli <petrilli(at)gmail(dot)com>, Ying Lu <ying_lu(at)cs(dot)concordia(dot)ca>, pgsql-general(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL
Date: 2005-05-10 19:50:05
Message-ID: 25690.1115754605@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

Greg Stark <gsstark(at)mit(dot)edu> 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).

No, not at all, because searching such an index will require a tree
descent, thus negating the one true advantage of hash indexes. I see
the potential value of sorting by hashcode within an individual page,
but that doesn't mean we should do the same across the whole index.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marc G. Fournier 2005-05-10 19:51:09 SECURITY RELEASES: 7.2.8 - 7.3.10 - 7.4.8 - 8.0.3
Previous Message mmiranda 2005-05-10 19:37:16 sequence values question

Browse pgsql-performance by date

  From Date Subject
Next Message Chris Browne 2005-05-10 20:14:05 Re: Prefetch - OffTopic
Previous Message Mohan, Ross 2005-05-10 19:17:07 Prefetch - OffTopic