Re: Hash indexes (was: On-disk bitmap index patch)

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)skype(dot)net>, Luke Lonergan <LLonergan(at)greenplum(dot)com>, mark(at)mark(dot)mielke(dot)cc, Bruce Momjian <bruce(at)momjian(dot)us>, Jie Zhang <jzhang(at)greenplum(dot)com>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hash indexes (was: On-disk bitmap index patch)
Date: 2006-07-28 19:14:33
Message-ID: 20060728191433.GA3115@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim C. Nasby wrote:

> What I'm getting at is that I've never seen any explanation for the
> theoretical use cases where a hash index would outperform a btree. If we
> knew what kind of problems hash indexes were supposed to solve, we could
> try and interest people who are solving those kinds of problems in
> fixing hash indexes.

The btree index needs to descend potentially many pages before getting
to the leaf page, where the actual index is stored. The hash index can
get at the "leaf" node in --supposedly-- one fetch. Btree is O(logN) to
get a single key, while hash is O(1). Our problem lies in the
constants; for btree they are smaller than for hash, so in practice
that O(logN) is always smaller than O(1).

I've heard other database systems manage to have hash indexes that are
actually faster than btree, so either (1) our btree absolutely rocks, or
(2) their hash implementations are better (probably both).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Luke Lonergan 2006-07-28 19:17:53 Re: On-disk bitmap index patch
Previous Message Tom Lane 2006-07-28 19:01:36 Re: Role incompatibilities