Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id ECDC5B5DC29 for ; Mon, 19 Sep 2011 12:35:48 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 69652-03 for ; Mon, 19 Sep 2011 15:35:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 91663B5DBCE for ; Mon, 19 Sep 2011 12:35:42 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p8JFZcbP017651; Mon, 19 Sep 2011 11:35:38 -0400 (EDT) To: Robert Klemme cc: Merlin Moncure , Stefan Keller , Jeff Janes , Peter Geoghegan , pgsql-performance@postgresql.org Subject: Re: Hash index use presently(?) discouraged since 2005: revive or bury it? In-reply-to: References: Comments: In-reply-to Robert Klemme message dated "Mon, 19 Sep 2011 17:19:14 +0200" Date: Mon, 19 Sep 2011 11:35:38 -0400 Message-ID: <17650.1316446538@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.404 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-0.504 X-Spam-Level: X-Archive-Number: 201109/271 X-Sequence-Number: 45047 Robert Klemme 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