On 11/01/2013 09:49 AM, Tom Lane wrote:
Dimitri Fontaine <dimi...@2ndquadrant.fr> writes:
Here's an idea: when a user ask for an Hash Index transparently build a
BTree index over an hash function instead.
-1. If someone asks for a hash index, they should get a hash index.
If you feel the documentation isn't sufficiently clear about the problems
involved, we can work on that.
The bigger picture here is that such an approach amounts to deciding that
no one will ever be allowed to fix hash indexes. I'm not for that, even
if I'm not volunteering to be the fixer myself.
I also don't believe your claim that this would always be faster than a
real hash index. What happened to O(1) vs O(log N)?
Lastly: what real-world problem are we solving by kicking that code
to the curb?
Yeah, and there's this: I've had at least one client who switched to
using hash indexes and got a significant benefit from it precisely
because they aren't WAL logged. They could afford to rebuild the indexes
in the unlikely event of a crash, but the IO gain was worth it to them.
Neither could they have tolerated unlogged tables - they wanted crash
safety for their data. After talking through the various options with
them they decided this was the best choice, and it might be sad to
remove that choice from people.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
