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