----- 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]