Robert Klemme <shortcutter@xxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
