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

From Merlin Moncure
Subject Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Date
Msg-id CAHyXU0w3HniZ58tbNWtBL=_uxqbsuu7Qq_TqHLHF-nF7v8FfZA@mail.gmail.com
Whole thread Raw
In response to Re: Hash index use presently(?) discouraged since 2005: revive or bury it?  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
List pgsql-performance
On Mon, Sep 19, 2011 at 1:53 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 3:43 PM, Merlin Moncure <mmoncure@gmail.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.

just selects.  update test is also very interesting -- the only test I
did  for for updates is 'update foo set x=x+1' which was a win for
btree (20-30% faster typically).  perhaps this isn't algorithm induced
though -- lack of wal logging could actually hurt time to commit
because it deserializes i/o.

merlin

pgsql-performance by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Postgres INSERT performance and scalability
Next
From: Venkat Balaji
Date:
Subject: : Performance Improvement Strategy