This technique is used extensively in disk cacheing and in maintaining file directories with huge numbers of files..
I would expect it toincrease key insertion speed because it removes a level of index in the B-tree of each index. The expensive activity in a B-tree index insertion is a node split which requires that key information be updated in each internal node level and possibly a new level added. Fewer levels mean faster performance. This method could also be used to add parallelism by having multiple threads or processes perform insertions concurrently. Having each database in a separate databases would help this approach. It would also help with concurrent read accesses. If this application only has one table and does not need SQL then there are better solutions than using Sqlite and paying the price for its many features but not using them. Kosenko Max wrote: > John Stanton-3 wrote: > >> Why would it not work? It is just adding an extra top level to the >> index. A tried and true method. >> > > It will work. But won't give performance benefit. And from my undestanding > it will even slow down things. > You can place parts of index in different DB and on different HDD thinking > it will boost the performance. > > But the problem is that we aren't talking about multiply selects at the same > time... We are talking about updating index in sqlite which is > single-threaded and even under load that wouldn't give you any advantages. > > Moreover you're emulating part of B-Tree with that approach and making it > slower and more space consumptive. So should it work as a solution? No. > > You have an idea why it should work? Tell me so. > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
