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

Robert Klemme <shortcutter@googlemail.com> writes:
> I still haven't seen a solution to locking when a hash table needs
> resizing.  All hashing algorithms I can think of at the moment would
> require a lock on the whole beast during the resize which makes this
> type of index impractical for certain loads (heavy updating).

That seems rather drastically overstated.  The existing hash index code
only needs to hold an index-scope lock for a short interval while it
updates the bucket mapping information after a bucket split.  All other
locks are per-bucket or per-page.  The conflicting share-lockers of the
index-wide lock also only need to hold it for a short time, not for
their whole indexscans.  So that doesn't seem to me to be materially
worse than the locking situation for a btree, where we also sometimes
need exclusive lock on the btree root page, thus blocking incoming
indexscans for a short time.

            regards, tom lane