On Mar 5, 2010, at 12:50 AM, Luke Evans wrote: > 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?
Maybe, if you disable shared-cache. Of course then you will use more memory, make more read() calls etc. Each shared-cache has associated with it a mutex. The mutex is held for the duration of each sqlite3_step() call on a statement handle that accesses that shared-cache. Dan. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
