Hi Dan, > > I have to correct myself a little... the hanging sqlite3_open_v2() does > > not happe while the prepare of the first query but during the first > > sqlite3_step() of the first query... > > Each shared-cache has a mutex associated with it. When > sqlite3_step is called it grabs the mutexes for all shared-caches > it might use. The mutexes are not released until the call > to sqlite3_step() returns. > > So if you have one query that spends a lot of time in sqlite3_step() > you are going to block your other threads. Unfortunately, that is > the nature of shared-cache mode.
Thanks for the info. But is this even true when enabling read uncommitted isolation mode using: sqlite3_exec(log_database_local, "PRAGMA read_uncommitted=True;", NULL, 0,&err) ?? I suspect it's the master table lock that is hold there, right? Any other chance to speed this up (apart from the obvious "optimize the query, do not use distinct on large tables....)= Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Geschäftsführer: Jörg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
