On 26 May 2017, at 6:00am, Wout Mertens <wout.mert...@gmail.com> wrote:
> Ideally there'd be some way to know if a _step() call will be served from > buffer… There are (simplified) three possibilities: quick quick, slow slow, and slow quick. A) SQLite finds a good index for the search/sort and can easily locate all the rows it needs to execute the call. In this case, both the initial _step() and all the others will execute quickly. B) SQLite can’t find an ideal index for the query but finds one which will allow it to execute the query acceptably, just skipping down the table identifying which rows should be processed. In this case, both the initial _step() and all the others will execute slowly. But if the table is short, or if your command needs to execute a large proportion of the rows in the table that might not be very slowly. C) SQLite can’t find any helpful indexes and decides that the most efficient way to execute the command involves making a temporary index. In this case, the initial _step() can take a long time but subsequent _step()s can be fast. Here’s the thing. An experienced SQLite programmer creates indexes suited to all WHERE and ORDER BY clauses they use, and then executes ANALYZE. If you do this, SQLite can always do (A), and because everything executes quickly there’s little advantage to asynchronous queries. The only time you really need to worry about (B) and (C) is when you provide facilities to your user allowing them to make up their own selection or sort order. Of course, your particular needs may include this. I can’t speak to how useful it will be to handle _step() synchronously in real life applications. Most of my applications are web-facing systems and handle their SQLite databases asynchronously because that’s how server access works in JS. They make HTTP calls to a PHP application running on a server. But for SELECT commands there’s really little they can do until they’ve got the first line back and know whether there are any rows. Maybe prepare a few DOM structures for the results, but that doesn’t take long. Hope this helps. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
