Re: Save Hash Indexes - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: Save Hash Indexes
Date
Msg-id CAAZKuFb+VcJBxxO0rZmayzOANkFBw3xVHHwRMh2sZwEwsLz8Ew@mail.gmail.com
Whole thread Raw
In response to Save Hash Indexes  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Save Hash Indexes  (Daniel Farina <daniel@heroku.com>)
List pgsql-hackers
On Fri, Nov 1, 2013 at 6:31 AM, Dimitri Fontaine <dimitri@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
thestern 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.



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Save Hash Indexes
Next
From: Noah Misch
Date:
Subject: Re: Something fishy happening on frogmouth