> 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. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq