"Pavel Ivanov" <paiva...@gmail.com> schrieb im Newsbeitrag news:f3d9d2131003051131k23c7b61cueda0bcc72e6aa...@mail.gmail.com...
Oops, pressed send unintentionally... > > Long story short - I suspect the open-call, to be the "blocker" > > in your "SharedCache-Mode=Off"-scenario. > If database file is pretty large, query reads a lot of data while > executing and all data read fit into database cache configured > then I think I/O will be the main difference between "with-shared- > cache" and "without-shared-cache" scenarios. The rest of your reply was probably meant for Luke, but the statement above is from my post, so ... >From his timing-results Luke clearly reports blocking behaviour with Shared-Cache=Off (although the blocking should only be reasonable with Shared-Cache=On) ... So, since everybody seems to agree about, that without Shared-Cache the blocking on sqlite3_step() should *not* happen - I suspect the open-calls (in each threaded request) to be the culprit. So, I don't mean my post with regards to the additional overhead from the open-call, doing its "real work" (schema- info-parsing and stuff) - instead from the results Luke has posted, I'd think, that there's an active mutex in the open-sequence- actions of SQLite, which prevents the parallelism. Olaf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users