Re: Hash index use presently(?) discouraged since 2005: revive or bury it? - Mailing list pgsql-performance

From Tom Lane
Subject Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Date
Msg-id 17650.1316446538@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hash index use presently(?) discouraged since 2005: revive or bury it?  (Robert Klemme <shortcutter@googlemail.com>)
List pgsql-performance
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

pgsql-performance by date:

Previous
From: Vitalii Tymchyshyn
Date:
Subject: Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Next
From: Vitalii Tymchyshyn
Date:
Subject: Re: Hash index use presently(?) discouraged since 2005: revive or bury it?