Re: Why hash indexes suck

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

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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 ?