On 3/28/07, Joe Wilson <[EMAIL PROTECTED]> wrote:
I believe 2 measures when applied together would significantly
improve insert speed of indexed rows:
1. Allot each index/btree a contiguous region of the database file in
which to grow without conflicting with the other indexes' pages and pages
of the underlying table itself. (Putting indexes in separate files if
only temporarily for bulk insert would be better, but hey, it's SQLite).
2. Adjust the btree algorithm to create larger gaps in the data when you
make space for new keys in the btree. Such page-sized gaps could minimize
much of the page shuffling currently done.
First I have to say I have no experience on database optimization
techniques (and it's my last mail before going to bed), but maybe the
possibility of having different index data structures (instead of only
the b-tree one) could also help?
My idea is that if we could create an index that uses an hash table,
possibly with a b-tree to handle collisions, maybe it would make
random inserts faster? It would spread the insertions on smaller
b-tree's.
Off course that leaves the problem of finding the right hash function,
but I suppose there are already pretty good generic (and fast) ones.
My guess is that it should be an hash function that spreads the
calculated hash in an ordered way, so one could walk the hash table in
a similar way than an ordered directory.
Regards,
~Nuno Lucas
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
