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

On Thu, Sep 15, 2011 at 3:28 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Thu, Sep 15, 2011 at 5:00 PM, Merlin Moncure <mmoncure(at)gmail(dot)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