Re: todo: Hash index creation

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, twraney(at)comcast(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: todo: Hash index creation
Date: 2007-06-28 01:33:44
Message-ID: 20070628013344.GC17397@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 27, 2007 at 08:36:54PM -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> > twraney(at)comcast(dot)net wrote:
> >> Is anyone currently working on this TODO item?
> >> "During index creation, pre-sort the tuples to improve build speed"
>
> > If you want to work on hash indexes, though, this TODO item seems more
> > important to me at least:
> >> Add WAL logging for crash recovery
>
> Actually I think the *most* important thing to work on is to get hash to
> the point where its search speed actually beats btree consistently, so
> that it has an excuse to live. If that is insoluble we might well end up
> ripping it out entirely. (The first three TODO items for hash indexes
> are ideas for trying to improve the speed.)
>
> Fixing the WAL support would come after that, and bring it to the point
> where someone could actually recommend it for production use.
>
> After that it would be sensible to work on inessentials like improving
> the build speed.
>
> regards, tom lane
>

I definitely agree with Tom's assessment. If we cannot need to make the
hash index as performant as it is in theory, none of the other refinements
are worth it. You would need to use BTree if you were concerned about
speed. (and who isn't)

Ken

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2007-06-28 01:38:58 Re: What does Page Layout version mean? (Was: Re: Reducing NUMERIC size for 8.3)
Previous Message Tom Lane 2007-06-28 00:36:54 Re: todo: Hash index creation