Hi SQLiters, We're currently investigating SQLite in an application that needs to issue a batch of queries (SELECTs) before doing some work with all the data returned.
I have been trying to figure out the fastest way to get the results. Given there are no writes involved, I figured there might be some advantages in having the queries run on separate threads, with a connection each, but with a shared cache and the read uncommitted flag set ON. This works fine, but the cumulative time for all the queries is in the same ballpark as if the queries were serialised, despite having SQLITE_CONFIG_MULTITHREAD set, SQLLITE_CONFIG_MEMSTATUS off, with SQLITE_OPEN_SHAREDCACHE and SQLITE_OPEN_NOMUTEX used on open. So, I'm not sure exactly how to configure (build and runtime) SQLite so it allows database reads to be essentially independent and lock-free. As an experiment, I wrote a simple program to do the same kind of query and ran several of these in parallel as processes (against the same database file). In this case, I'm seeing very parallel behaviour, and all queries complete in just over the time it would normally take for a single one. The process experiment seems to confirm that very fast independent parallel queries can be made on the same database, but clearly I would like the same behaviour using multiple threads (and probably connections) in the same process. Is this possible with some specific configuration of SQLite? Cheers! -- Luke _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
