"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

Reply via email to