| From: | Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dann Corbit <DCorbit(at)connx(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Why hash indexes suck |
| Date: | 2004-06-05 20:15:25 |
| Message-ID: | mjq65a5ep7m.fsf@cs.berkeley.edu |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
Tom> This means that if you have only one or a few items per
Tom> bucket, the information density is awful, and you lose big on
Tom> I/O requirements compared to a btree index. On the other
Tom> hand, if you have enough items per bucket to make the storage
Tom> density competitive, you will be doing linear searches
Tom> through dozens if not hundreds of items that are all in the
Tom> same bucket, and you lose on CPU time (compared to btree
Tom> which can do binary search to find an item within a page).
This is probably a crazy idea, but is it possible to organize the data
in a page of a hash bucket as a binary tree ? Then you wouldn't lose
wrt CPU time at least.
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-06-05 20:31:12 | Re: Why hash indexes suck |
| Previous Message | Tom Lane | 2004-06-05 20:03:39 | Why hash indexes suck |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-06-05 20:24:05 | Re: I/O support for composite types |
| Previous Message | David Garamond | 2004-06-05 20:11:02 | Re: [HACKERS] Not 7.5, but 8.0 ? |