Re: What is wrong with hashed index usage?

Поиск
Список
Период
Сортировка
От Michael Loftis
Тема Re: What is wrong with hashed index usage?
Дата
Msg-id 3CC4A12F.70700@wgops.com
обсуждение исходный текст
Ответ на Re: What is wrong with hashed index usage?  ("Dann Corbit" <DCorbit@connx.com>)
Ответы Re: What is wrong with hashed index usage?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: What is wrong with hashed index usage?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
The benchmarks will depend mostly on the depth of the Btree.   Hashes 
will be markedly faster only in the case(s) where descending into the 
tree to produce a matching leaf node would take longer than walking to 
the appropriate item in a hash.

Most of the time until the btree gets deep they are nearly equivalent. When the tree ends up becoming many levels deep
itcan take longer to 
 
walk than the hash.

Neil Conway wrote:

>On Mon, 22 Apr 2002 15:04:22 -0700
>"Dann Corbit" <DCorbit@connx.com> wrote:
>
>>Here is where a hashed index shines:
>>To find a single item using a key, hashed indexes are enormously faster
>>than a btree.
>>
>>That is typically speaking.  I have not done performance benchmarks with
>>PostgreSQL.
>>
>
>Yes -- but in the benchmarks I've done, the performance different
>is not more than 5% (for tables with ~ 600,000 rows, doing lookups
>based on a PK with "="). That said, my benchmarks could very well
>be flawed, I didn't spend a lot of time on it. If you'd like to
>generate some interest in improving hash indexes, I'd like to see
>some empirical data supporting your performance claims.
>
>Cheers,
>
>Neil
>




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

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Documentation on page files
Следующее
От: Joe Conway
Дата:
Сообщение: Re: Simplifying OID lookups in the presence of namespaces