Kenneth Marshall wrote:
I definitely agree with Tom's assessment. If we cannot need to make the
hash index as performant as it is in theory, none of the other refinements
are worth it. You would need to use BTree if you were concerned about
speed. (and who isn't)


I just got an idea.

Hash indexes would take much less space, and be more efficient to search, if we only stored the hash of the key in the index. Such index tuples would be fixed size, so we could get rid of the overhead of the length-field in IndexTuple, as well as the line pointers.

Of course, the key value would need to be rechecked after fetching the heap tuple, but that shouldn't be a problem assuming there's few collisions.

Another idea: when searching, we scan the whole bucket page looking for matching tuples. If we stored the tuples ordered by hash value within page, we could do a binary search instead.

These changes might give hash indexam the edge over b-tree it needs.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to