[sqlite] caching sqlite3_db_mutex()

Hi, Is it safe to cache the mutex pointer returned by `sqlite3_db_mutex(sqlite3*)`? Can/does the mutex pointer change thought the life of the `sqlite3` object? Thanks, Baruch -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ sqlite-users

Re: [sqlite] caching sqlite3_db_mutex()

On 5/25/17, Baruch Burstein wrote: > > Is it safe to cache the mutex pointer returned by > `sqlite3_db_mutex(sqlite3*)`? > Can/does the mutex pointer change thought the life of the `sqlite3` object? > I think so, yes. (Warning: This answer given in the early morning,

Re: [sqlite] Memory Issue - GLOBs and Windows Active Mapped File

On Wednesday, 24 May, 2017 18:48, Jamie wrote: > When I'm performing a large amount of selects of GLOBs/thumbnails from an > ongoing SQLiteConnection, I'm having a problem where the Windows Active > Mapped File will constantly grow out of control in size (memory leak?). >

Re: [sqlite] Memory Issue - GLOBs and Windows Active Mapped File

> What you are observing is the Windows System File Cache. I already explained this is not the normal Windows File Caching that you would typically see. File Caching would be under STANDBY Mapped File and can be easily removed from RAM when memory is needed for something else. You can even

Re: [sqlite] Memory Issue - GLOBs and Windows Active Mapped File

I tried changing it to several different values for that pragma, but it did not seem to have any affect on how large the Active Mapped File could grow. The pragma was set before anything else was done on the connection. Although futile; I also tried attempting to use the pragma on the

Re: [sqlite] auntondex with unique and integer primary key

On 26 May 2017, at 2:47am, James K. Lowden wrote: > Nothing about any SQL statement implies anything about the > implementation. Thus, as you know, a unique constraint is not an > instruction to build an index, much less a requirement to build a > redundant one. It's

Re: [sqlite] auntondex with unique and integer primary key

On Fri, 19 May 2017 13:06:23 -0600 "Keith Medcalf" wrote: > You asked for the extra index to be created in the table > specification. It is not the job of the database engine to correct > your errors (it is not even possible to know if it is an error). He didn't ask.

[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

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