On Wed, 2003-11-05 at 23:59, Jonas Forsman / Axier.SE wrote: > According to the postgresql documentation, the hash algorithm is > discouraged compared to b-tree for performance reasons. > > http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=indexes-types.html > > 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. Further, the length of our btrees drops by 1/n-1 per insert. This speeds up the insert of random data. Because SQLite only supports a single-writer OR multiple-readers this operation is relatively sane. If concurrency were desirable, the initial inserts to the tops of the btree become a lot more complicated-- but then, so does the btree itself... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
