On Thu, 2 May 2013 11:16:06 +0200
"Jan Slodicka" <j...@resco.net> wrote:
> I was testing various ways how to interrupt rebuilding of an FTS
> index. Ability to abort is vital as the app is running on a
> smartphone and has to meet responsivity requirements.
>
> Here is what SQLite offers (AFAIK):
> - Progress handler (with low nOps value): Relatively good with only
> occasional longer periods without progress handler invocation. High
> nOps values perform badly.
> - Authorizer: Does not help much in itself, but improves a bit the
> progress handler as it is called at different occasions.
> - sqlite3_interrupt(): Tested once per sqlite3VdbeExec() call (also
> during SQL parsing, sqlite3Step()...) => insufficient.
>
> Suggestion:
> The progress handler is called when {operation_counter=i*nOps; i>0},
> whereby the counter is reset at entry to sqlite3VdbeExec() and then
> incremented for each VDBE operation. This reset causes irregular
> behavior with occasional long periods without progress handler
> invocation. So the suggestion is: Make the counter global per DB
> connection and do not reset it.
>
> The real problem is that even if I use all above tools (progress
> handler with nOps=1), there are relatively long periods when the
> execution cannot be interrupted. For example for a 30MB table (the
> user data may be larger) there is roughly 0.5 sec pause at the end
> (measured on the desktop!), maybe caused by journal maintenance.
What are your settings for pragmas "cache_size", "journal_mode" and
"synchronous"?
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
