From: | Michael Loftis <mloftis(at)wgops(dot)com> |
---|---|
To: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
Cc: | Dann Corbit <DCorbit(at)connx(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: What is wrong with hashed index usage? |
Date: | 2002-04-22 23:47:59 |
Message-ID: | 3CC4A12F.70700@wgops.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 it can take longer to
walk than the hash.
Neil Conway wrote:
>On Mon, 22 Apr 2002 15:04:22 -0700
>"Dann Corbit" <DCorbit(at)connx(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-04-23 03:35:03 | Re: Simplifying OID lookups in the presence of namespaces |
Previous Message | Martijn van Oosterhout | 2002-04-22 23:29:28 | Re: Documentation on page files |