| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, 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 23:56:15 |
| Message-ID: | 87ll6mr5y8.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-performance |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> No, not at all, because searching such an index will require a tree
> descent, thus negating the one true advantage of hash indexes.
The hash index still has to do a tree descent, it just has a larger branching
factor than the btree index.
btree indexes could have a special case hack to optionally use a large
branching factor for the root node, effectively turning them into hash
indexes. That would be useful for cases where you know the values will be very
evenly distributed and won't need to scan ranges, ie, when you're indexing a
hash function.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mischa Sandberg | 2005-05-11 00:14:26 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
| Previous Message | Peter Fein | 2005-05-10 23:43:28 | Re: JOIN on set of rows? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mischa Sandberg | 2005-05-11 00:14:26 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
| Previous Message | Mischa Sandberg | 2005-05-10 23:24:01 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |