----- Forwarded by Ben Carlyle/AU/IRSA/Rail on 07/11/2003 10:00 AM -----
Ben Carlyle
07/11/2003 10:00 AM
To: "Mrs. Brisby" <[EMAIL PROTECTED]>@CORP
cc:
Subject: Re: [sqlite] Performance problem
"Mrs. Brisby" <[EMAIL PROTECTED]>
07/11/2003 12:08 AM
To: "Jonas Forsman / Axier.SE" <[EMAIL PROTECTED]>
cc: "Clark, Chris" <[EMAIL PROTECTED]>, "D. Richard Hipp" <[EMAIL
PROTECTED]>,
[EMAIL PROTECTED]
Subject: Re: [sqlite] Performance problem
> On Wed, 2003-11-05 at 23:59, Jonas Forsman / Axier.SE wrote:
> > Note: Testing has shown PostgreSQL's hash indexes to be similar or
slower
> > than B-tree indexes, and the index size and build time for hash
indexes is
> > much worse. Hash indexes also suffer poor performance under high
> > concurrency. For these reasons, hash index use is discouraged.
> Please note I'm note I'm not talking about a hash of the entire key- I'm
> talking about n distinct b-trees that are selected by an 8->n bit
> function. This transformation can be made very fast: We get a speed
> improvement here on searches if our 8->n bit function takes less time
> than n-1 random memcmp()'s.
How would you handle the lack of ordering associate with hash tables?
Sqlite can currently use indicies for three main tests: equals, less than,
and greater than. While hash-tables are good at finding equal-to in
constant time it usually means linear time (a table-scan) to test for less
than or greater than. Do you have a solution to this problem?
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
