"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > Gregory Stark wrote: >> For i/o-bound databases with very large indexes there should be an >> opportunity >> where btree lookups are O(logn) and hash lookups can in theory be O(1). > > Ignoring the big-O complexity, if a hash index only stores a 32-bit hash code > instead of the whole key, it could be a big win in storage size, and therefore > in cache-efficiency and performance, when the keys are very long.
I think it has to show an improvement over an expression index over (hashany(col)) and not just an improvement over an index over "col" due to col being large. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
