On Thu, Sep 15, 2011 at 3:28 PM, Claudio Freire <klaussfre...@gmail.com> wrote: > On Thu, Sep 15, 2011 at 5:00 PM, Merlin Moncure <mmonc...@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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
