Re: Hash index use presently(?) discouraged since 2005: revive or bury it?

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Дата
Msg-id CAHyXU0zHWYAgNghgxQ4PaR3okepqxC8enBpOw6OUm0M4aJWJtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Hash index use presently(?) discouraged since 2005: revive or bury it?  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-performance
On Thu, Sep 15, 2011 at 3:28 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 5:00 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>
>> HM, what if you junked the current hash indexam, and just implemented
>> a wrapper over btree so that the 'hash index' was just short hand for
>> hashing the value into a standard index?
>
> I'm doing this (only by hand, indexing on hash(blah)) on an
> application, and it works wonders.
> But... it's kinda not a hash table. It's still O(log N).
>
> However, it would be a *very* useful feature if it can be made
> transparent for applications.
> And I would prefer it over a true hashtable, in the end. Hashes are,
> in fact, O(N) worst case.

yeah -- in my (limited) testing, with int4 or int8, btree handily
meets or beats hash on creation, access time, and index size.  this
suggests to me that a separate index implementation for hash isn't
buying us much -- the integer btree code is highly optimized.

merlin

В списке pgsql-performance по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Hash index use presently(?) discouraged since 2005: revive or bury it?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Hash index use presently(?) discouraged since 2005: revive or bury it?