Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 058D2B5DC0F for ; Wed, 14 Sep 2011 20:40:33 -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 29847-03 for ; Wed, 14 Sep 2011 23:40:22 +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 924E1B5DC19 for ; Wed, 14 Sep 2011 20:40:22 -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 p8ENeIXS008906; Wed, 14 Sep 2011 19:40:18 -0400 (EDT) To: Stefan Keller cc: Peter Geoghegan , pgsql-performance@postgresql.org Subject: Re: Hash index use presently(?) discouraged since 2005: revive or bury it? In-reply-to: References: <16096.1315959870@sss.pgh.pa.us> Comments: In-reply-to Stefan Keller message dated "Thu, 15 Sep 2011 01:03:46 +0200" Date: Wed, 14 Sep 2011 19:40:18 -0400 Message-ID: <8905.1316043618@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/222 X-Sequence-Number: 44998 Stefan Keller writes: > 2011/9/14 Tom Lane writes: >> (...) I think that >> the current state of affairs is still what depesz said, namely that >> there might be cases where they'd be a win to use, except the lack of >> WAL support is a killer. I imagine somebody will step up and do that >> eventually. > How much of work (in man days) do you estimate would this mean for > someone who can program but has to learn PG internals first? No idea ... I'm probably not the best person to estimate how long it would take someone to get up to speed on the relevant internals, but I'm sure that would take longer than actually doing the work. While it's not a trivial task, I think it fits the definition of "a small matter of programming": a piece of code whose anticipated length is significantly greater than its complexity. regards, tom lane