Re: [sqlite] [EXTERNAL] Re: sqlite3_progress_handler(D,N,X,P)

I can't tell without extensively looking into the source code. I expect not. From my experience I would infer that ResultRow and maybe a few other VMIs are actual "interrupt points", because complex joins of virtual tables can continue for extended periods of time (and read tons of rows) before

Re: [sqlite] [EXTERNAL] sqlite3_progress_handler(D,N,X,P)

Just tried sqlite3_interrupt but it didn’t seem to help. I presume there’s no interrupt points within the count() function mentioned in the explain. From: sqlite-users on behalf of Hick Gunter

Re: [sqlite] sqlite3_progress_handler(D,N,X,P)

Thanks for your input Ryan. I do think milliseconds would be more intuitive rather than having to guess the number of VMI’s that will be computed. The problem in the case I quote though is that there is only a few VMI’s for “select count(*) from Tbl” one of which is a call to the special

Re: [sqlite] [EXTERNAL] sqlite3_progress_handler(D,N,X,P)

If you want elapsed milliseconds, you can set a timer and call sqlite3_interrupt() to have sqlite quit executing the query as soon as possible. This interface is based on "work done". I guess the callback routine gets called at the next "interrupt point" (which is why the number N is only

Re: [sqlite] sqlite3_progress_handler(D,N,X,P)

On 2018/05/24 5:41 PM, x wrote: The parameter N is the approximate number of virtual machine instructions that are evaluated between successive invocations of the callback X. Would it not have been better if N was the number of milliseconds between

[sqlite] sqlite3_progress_handler(D,N,X,P)

The parameter N is the approximate number of virtual machine instructions that are evaluated between successive invocations of the callback X. Would it not have been better if N was the number of milliseconds between invocations? It’s not much use if you want to