| 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: | Whole Thread | Raw Message | 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
| 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 |
| 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 |