| From: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
| Cc: | "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Dann Corbit" <DCorbit(at)connx(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:53:56 |
| Message-ID: | 36e682920807180753k3c5d3fdhc0ad4d2f12bafe13@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 18, 2008 at 10:44 AM, Heikki Linnakangas
<heikki(at)enterprisedb(dot)com> wrote:
> 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.
Agreed. My thinking is that there's either something inherently wrong
with the implementation, or we're performing so many disk I/Os that
it's nearly equivalent to b-tree. Tom has a couple suggestions which
Xiao and I will explore.
> Granted, it's not very common to use a 1K text field as a key column...
Especially for direct equality comparison :)
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah(dot)harris(at)enterprisedb(dot)com
Edison, NJ 08837 | http://www.enterprisedb.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-07-18 14:55:13 | Re: TABLE-function patch vs plpgsql |
| Previous Message | Gregory Stark | 2008-07-18 14:52:10 | Re: [PATCH]-hash index improving |