Re: Hash index use presently(?) discouraged since 2005: revive or bury it? - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Date
Msg-id CAHyXU0zHWYAgNghgxQ4PaR3okepqxC8enBpOw6OUm0M4aJWJtA@mail.gmail.com
Whole thread Raw
In response to Re: Hash index use presently(?) discouraged since 2005: revive or bury it?  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-performance
On Thu, Sep 15, 2011 at 3:28 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 5:00 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>
>> HM, what if you junked the current hash indexam, and just implemented
>> a wrapper over btree so that the 'hash index' was just short hand for
>> hashing the value into a standard index?
>
> I'm doing this (only by hand, indexing on hash(blah)) on an
> application, and it works wonders.
> But... it's kinda not a hash table. It's still O(log N).
>
> However, it would be a *very* useful feature if it can be made
> transparent for applications.
> And I would prefer it over a true hashtable, in the end. Hashes are,
> in fact, O(N) worst case.

yeah -- in my (limited) testing, with int4 or int8, btree handily
meets or beats hash on creation, access time, and index size.  this
suggests to me that a separate index implementation for hash isn't
buying us much -- the integer btree code is highly optimized.

merlin

pgsql-performance by date:

Previous
From: Claudio Freire
Date:
Subject: Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Next
From: Tom Lane
Date:
Subject: Re: Hash index use presently(?) discouraged since 2005: revive or bury it?