Re: Save Hash Indexes

Поиск
Список
Период
Сортировка
От Daniel Farina
Тема Re: Save Hash Indexes
Дата
Msg-id CAAZKuFb+VcJBxxO0rZmayzOANkFBw3xVHHwRMh2sZwEwsLz8Ew@mail.gmail.com
обсуждение исходный текст
Ответ на Save Hash Indexes  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Save Hash Indexes  (Daniel Farina <daniel@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Save Hash Indexes
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Something fishy happening on frogmouth