On 31 Dec 2018, at 9:10pm, Jesse Rittner <rittneje+sql...@gmail.com> wrote:
> Simon Slavin-3 wrote > >> You can calculate an "end time" yourself, check it each time you're ready to >> call sqlite3_step(), and jump straight to sqlite3_finalize() if your time is >> up. > > I'm not familiar with the inner workings of sqlite3_step, but if that itself > takes time, then I'd like to interrupt the call prematurely. [The following is simplified for clarity.] The first call to sqlite3_step() can take time if there's no good index for your operation. It may have to construct its own temporary index. Of course, creation of a temporary index will happen only if you haven't thought through your clauses (WHERE, GROUP BY, ORDER BY, Santa) and created a good index that deals with them all. If you have a 100 Gig table with no indexes suited to your clauses, creating a temporary index might take a minute or two. But you really only have yourself to blame. Subsequent calls to sqlite3_step() rely on the preparation having been done. They just step through an index (permanent or temporary) which already exists. Such calls are very fast. Since the one possibly-long operation happens at the very beginning of the command, and it can be long only if you're a bad SQL programmer, it's unlikely that your timeout will happen during it. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
