Re: What is wrong with hashed index usage? - Mailing list pgsql-hackers

From Michael Loftis
Subject Re: What is wrong with hashed index usage?
Date
Msg-id 3CC4A12F.70700@wgops.com
Whole thread Raw
In response to Re: What is wrong with hashed index usage?  ("Dann Corbit" <DCorbit@connx.com>)
Responses 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>)
List 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 by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Documentation on page files
Next
From: Joe Conway
Date:
Subject: Re: Simplifying OID lookups in the presence of namespaces