From: | Naz Gassiep <naz(at)mira(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: todo: Hash index creation |
Date: | 2007-07-02 02:27:50 |
Message-ID: | 468862A6.4070303@mira.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
I've been warned away from hash indexes before, however I had no idea
that it's performance was that abysmal that BTREE beat it and I was
definitely not aware that they were not included in WAL logs. I was told
it wasn't as good as it could be, but I wasn't told it was pretty much
an alpha piece of code.
As a result, when creating tables containing large blocks of text I wish
to index, I've been using HASH as an index method. Please can we state
in the manual that HASH index types are in a beta stage of development
or something similar, or perhaps remove the manual entry altogether
until HASH is at a point where it is usable in production.
Regards,
A very surprised n00b.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-07-02 02:44:07 | Re: todo: Hash index creation |
Previous Message | Eric | 2007-07-02 02:20:08 | Re: GiST consistent function, expected arguments; multi-dimensional indexes |