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