On Fri, Nov 1, 2013 at 6:31 AM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Hi, > > Here's an idea: when a user ask for an Hash Index transparently build a > BTree index over an hash function instead. > > Advantages: > > - it works > - it's crash safe > - it's (much?) faster than a hash index anyways > > Drawbacks: > > - root access concurrency > - we need a hash_any function stable against pg_upgrade > > After talking about it with Heikki, we don't seem to find ways in which > the root access concurrency pattern would be visible enough to matter. > > Also, talking with Peter Geoghegan, it's unclear that there's a use case > where a hash index would be faster than a btree index over the hash > function. > > Comments?
I haven't met a single Heroku user that has stumbled into this landmine. Normally I am very weary of such landmine laden features, but this one is there and doesn't seem to have detonated at any point. I guess the obscure nature of those indexes and the stern warning in the documentation has sufficed to discourage their use. Given that experience, I think foreclosing fixing hash indexes is premature, and doesn't seem to be hurting inexperienced users of this stripe. Maybe there are yet other reasons to argue the subject, though...it's not like the current user base relies on the behavior as-is either, having seemingly steered clear just about altogether. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
