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:

Reply via email to