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