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 count() function (see “explain select count(*) from Tbl”). Once it enters the count() function there is no opportunity to cancel. I.e. either you get the count or you don’t.
Gunter, just seen your interesting post. Do you know if that would work while the count() function was being executed? ________________________________ From: sqlite-users <sqlite-users-boun...@mailinglists.sqlite.org> on behalf of R Smith <ryansmit...@gmail.com> Sent: Thursday, May 24, 2018 5:03:14 PM To: sqlite-users@mailinglists.sqlite.org Subject: 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<https://sqlite.org/opcode.html> 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 abort from a lengthy “select > count(*) from Tbl” as there are only a couple of virtual machine instructions > whereas “select count(*) from Tbl,Tbl” might have billions of VMI’s. I think VM steps generally happen in quick succession, never minutes apart. Either way, milliseconds elapsed is equally useless - plus what could possibly be easier than measuring time yourself? Pseudo code example, but it will work for near any platform with some numeric representation of "time". ... curtime = now; elapsed = curtime - prevtime; prevtime = curtime; ... print elapsed; ... What you cannot do, is deduce VM steps like that, so indeed you are better off with the progress handler reporting VM steps (which you cannot deduce) rather than elapsed time (which you can). What we REALLY want however, is to know the final intended VM steps so that curstep/finalstep will give us some idea of the progress, but it is impossible to know (even in principle) before the actual query result have been produced at least once. So at this point we are condemned to reporting to the user something like "Look mate, it's still busy, but at least the current VM steps > previous VM steps, so it ain't hung. Shall we wait some more, or cancel?" - to which the good user hopefully do not cancel prematurely (though that is hard to expect with zero confidence in which exact VM milestone constitutes "premature"). Luckily this is less of a problem in custom system code, since you can test every query, even on big data. It gets hard when you make a DB manager of sorts in which allowing ANY query is a necessity. Point being: There is no good answer to this. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
