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