| From: | Neil Conway <neilc(at)samurai(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "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 04:25:06 |
| Message-ID: | 428037A2.4060304@samurai.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-performance |
Tom Lane wrote:
> On the other hand, once you reach the target index page, a hash index
> has no better method than linear scan through all the page's index
> entries to find the actually wanted key(s)
I wonder if it would be possible to store the keys in a hash bucket in
sorted order, provided that the necessary ordering is defined for the
index keys -- considering the ubiquity of b+-trees in Postgres, the
chances of an ordering being defined are pretty good. Handling overflow
pages would be tricky: perhaps we could store the entries in a given
page in sorted order, but not try to maintain that order for the hash
bucket as a whole. This would mean we'd need to do a binary search for
each page of the bucket, but that would still be a win.
-Neil
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jerome Macaranas | 2005-05-10 04:35:28 | Re: Need input on postgres used for phpBB |
| Previous Message | Jerome Macaranas | 2005-05-10 04:19:43 | Re: Need input on postgres used for phpBB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-05-10 04:54:48 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |
| Previous Message | Tom Lane | 2005-05-10 04:10:57 | Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL |