Re: Hash index use presently(?) discouraged since 2005: revive or bury it?

From: Stefan Keller <sfkeller(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: jeff(dot)janes(at)gmail(dot)com, mmoncure(at)gmail(dot)com, peter(at)2ndquadrant(dot)com, pgsql-performance(at)postgresql(dot)org
Subject: Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Date: 2011-09-18 19:31:55
Message-ID: CAFcOn2_21Gds+725G8KTDFiTM+kz+3rG9-6zB37_9ge30dxkLg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I'm simply referring to literature (like the intro Ramakrishnan & Gehrke).
I just know that Oracle an Mysql actually do have them too and use it
without those current implementation specific restrictions in
Postgres.

IMHO by design Hash Index (e.g. linear hashing) work best when:
1. only equal (=) tests are used (on whole values)
2. columns (key values) have very-high cardinality

And ideally but not necessarily when index values do not change and
number of rows are known ahead of time (avoiding O(N) worst case - but
there are approaches to chaining with dynamic resizing).

I just collected this to encourage ourselves that enhancing hash
indexes could be worthwhile.

Stefan

2011/9/18 Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>:
> Stefan Keller  wrote:
>
>> It's hard for me to imagine that btree is superior for all the
>> issues mentioned before.
>
> It would be great if you could show a benchmark technique which shows
> otherwise.
>
> -Kevin
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Stefan Keller 2011-09-18 19:45:50 What about implementing a bitmap index? Any use cases?
Previous Message Kevin Grittner 2011-09-18 15:17:17 Re: Hash index use presently(?) discouraged since 2005: revive or bury it?