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
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 |