Re: Hash index use presently(?) discouraged since 2005: revive or bury it?

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Robert Klemme <shortcutter(at)googlemail(dot)com>, Stefan Keller <sfkeller(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Date: 2011-09-19 18:53:07
Message-ID: CAGTBQpYeKyfN4_qryv7O+biMPqjapLH4r4gNUOCrHgfbOAeZiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Sep 19, 2011 at 3:43 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> To make the test into i/o bound, I change the setrandom from 100000 to
> 10000000; this produced some unexpected results. The hash index is
> pulling about double the tps (~80 vs ~ 40) over the hybrid version.
> Well, unless my methodology is wrong, it's unfair to claim btree is
> beating hash in 'all cases'. hm.

Is this only selects?
Hash performs badly with updates, IIRC.
I haven't tried in a long while, though.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Igor Chudov 2011-09-19 22:11:11 Postgres INSERT performance and scalability
Previous Message Merlin Moncure 2011-09-19 18:43:06 Re: Hash index use presently(?) discouraged since 2005: revive or bury it?