On Sun, Sep 19, 2010 at 8:18 PM, Erik Fears <str...@strtok.net> wrote:
> This helps with the locking issues. > > I believe the slowness was actually related to the index on the 'name' > column. > This is a price you have to pay. The fastest scenario is when you don't have an index on a table and sequentially add new record to the table. Regardless of the db size and RAM available sqlite on every step probably uses the same pages (that already resides in cache) for b-tree updating and from time to time writes cached pages that were updated. But if an index exists, you will get significant drop in speed if you data to be indexed is really random and the index is not small enough to fit in RAM (via the sqlite or system cache). This is because almost every time sqlite needs to access pages that don't reside in cache. If you really just have to guarantee uniqueness of the field, a separated hash could give you speed increase if an average size of your hash entry much smaller than the size of your name field and you don't expect many collisions (since in case of collision you still have to access the original name field that actually kills your attempt to speed the things up). Max maxerist.net _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
