| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Dann Corbit" <DCorbit(at)connx(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, "Xiao Meng" <mx(dot)cogito(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Kenneth Marshall" <ktm(at)rice(dot)edu> |
| Subject: | Re: [PATCH]-hash index improving |
| Date: | 2008-07-18 14:52:10 |
| Message-ID: | 87r69rz1lx.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Gregory Stark wrote:
>> For i/o-bound databases with very large indexes there should be an opportunity
>> where btree lookups are O(logn) and hash lookups can in theory be O(1).
>
> Ignoring the big-O complexity, if a hash index only stores a 32-bit hash code
> instead of the whole key, it could be a big win in storage size, and therefore
> in cache-efficiency and performance, when the keys are very long.
I think it has to show an improvement over an expression index over
(hashany(col)) and not just an improvement over an index over "col" due to col
being large.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonah H. Harris | 2008-07-18 14:53:56 | Re: [PATCH]-hash index improving |
| Previous Message | chris | 2008-07-18 14:48:09 | Re: Postgres-R: primary key patches |