Eduardo Morras wrote: > At 13:10 29/10/2008, you wrote: > >> Look up the implications of Sqlite's ACID feature and the use of >> transactions. COMMITs are tied to disk rotation speed. On our Sqlite >> databases where we look for performance we use 15,000 rpm disks and are >> diligent in wrapping INSERTs, UPDATEs and DELETEs in transactions and >> get very good results. >> >> The Sqlite B-Tree indices do slow down on insertion as extra levels are >> created in the index as it grows large. That is an inherent feature of >> such structures. >> JS >> > > I think the problem is that he creates the index before insert the > data. He should insert the data using begin..commit and after insert > creates the indexes. If not, for each insert, the indexes must be > reworked/redone and slowdown happens > FWIW,
I've done some experiments in the past with large numbers of inserts trying it both ways, with the indexes intact during insert and by creating them after the fact, and I did not trace any significant differences in time. You mileage may vary as the type of work I am doing may simply not benefit, but my experience tells me that moving index creation is not a guaranteed way of improving performance. John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
