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

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Stefan Keller <sfkeller(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Date: 2011-09-17 21:48:29
Message-ID: CAMkU=1x7EsbLh8oxYtXKWzDx5HUDxQ2Vb4sFDCVY0FE8rnttSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Sep 13, 2011 at 5:04 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> On 14 September 2011 00:04, Stefan Keller <sfkeller(at)gmail(dot)com> wrote:
>> Has this been verified on a recent release? I can't believe that hash
>> performs so bad over all these points. Theory tells me otherwise and
>> http://en.wikipedia.org/wiki/Hash_table seems to be a success.

My understanding is that a huge amount of work has gone into making
btree what it is in
PG, and not nearly as much work has gone into making hash indexes what
they could be.

> Hash indexes have been improved since 2005 - their performance was
> improved quite a bit in 9.0. Here's a more recent analysis:
>
> http://www.depesz.com/index.php/2010/06/28/should-you-use-hash-index/

They are 3 time faster to build. But if you rip the WAL logging out
of btree, how much faster would those get?

Also, that link doesn't address concurrency of selects at all, only of inserts.

Cheers,

Jeff

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2011-09-17 22:11:33 Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Previous Message Jeff Janes 2011-09-17 20:21:50 Re: PG 9.x prefers slower Hash Joins?