Re: [sqlite] C API: which calls have the biggest chance of latency?

> On May 25, 2017, at 10:00 PM, Wout Mertens wrote: > > I would like to make it partially asynchronous, still doing most of the > work on the main thread, but waiting in a helper thread. I was thinking > that the longest delays will be from disk access, so sqlite_step().

Re: [sqlite] C API: which calls have the biggest chance of latency?

On 5/26/17, Wout Mertens wrote: > > Are the above assumptions correct? Any other calls (besides opening the db) > that can take a long time? Most of the work associated with opening the database connection (which is to say, parsing the schema) is deferred until the first

Re: [sqlite] C API: which calls have the biggest chance of latency?

On 2017/05/26 7:33 AM, Simon Slavin wrote: On 26 May 2017, at 6:00am, Wout Mertens 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

Re: [sqlite] C API: which calls have the biggest chance of latency?

On Fri, May 26, 2017 at 7:33 AM Simon Slavin wrote: > > On 26 May 2017, at 6:00am, Wout Mertens wrote: > > > Ideally there'd be some way to know if a _step() call will be served from > > buffer… > > There are (simplified) three possibilities: quick

Re: [sqlite] C API: which calls have the biggest chance of latency?

On 26 May 2017, at 6:00am, Wout Mertens 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

[sqlite] C API: which calls have the biggest chance of latency?

I am liking the simplicity of the better-sqlite3 Nodejs library, but it is synchronous (for some good reasons), so it will hang the main thread until sqlite is done. I would like to make it partially asynchronous, still doing most of the work on the main thread, but waiting in a helper thread. I