Re: What is wrong with hashed index usage?

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
>

In response to

Responses

Browse pgsql-hackers by date

  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