[sqlite] WAL mode much slower in certain use cases

I am using SQLite 3.24.0, as a single user persistent data store for storing simulation data. The database can grow to many gigabytes as the software can ingest a lot of binary data which I store as multiple BLOBs. In the following example I am reading several 22GB of data into the DB. Times

[sqlite] BLOB sizes beyond 2GB?

HI, Is it likely the maximum BLOB size will be increased in a not too distant future version of SQLite? In a world of machines where 1TB memory is not unusual the current upper limit of ~2GB is proving to be restrictive for my use. One might suggest that storing binary data of that size using

[sqlite] Possible bug in SQLite in sqlite3VdbeSorterInit for PMA sorter size

I am using the option to set the main cache size *PRAGMA **schema.**cache_size = -**kibibytes**;* In function sqlite3VdbeSorterInit it seems that the calculation of mxCache does not take into account the above alternate way to set cache_size that uses the *-**kibibytes* option.

[sqlite] sqlite-users Digest, Vol 94, Issue 4

> > Ok. My first guess is that you are missing the "suggested index" on the > child table. Without this, if there is a foreign key violation in the > db, each insert on the parent table will cause a linear scan of the > entire child table. With the index, it's just a simple seek. > >

[sqlite] (no subject)

> > > SQLite uses a counter to enforce deferred foreign keys. Each time an > operation violates a constraint it increments that counter. > > If the counter is greater than 0, then for every operation that might > potentially correct the violation (which means virtually every operation > on any

[sqlite] SQLite slows by a factor of 1000 after foreign key violation

I have noticed that when FOREIGN KEY is in DEFERRED mode and a FOREIGN KEY violation occurs, SQLite will continue to run, but performance slows down by about 1000x. Breaking into the code shows that it seems to be continually re-reading the database. When I finally get to COMMIT , an exception is

Re: [sqlite] Porting into a microcontroller, minimum requirements

*snip* "I have doubts that you will be able to get SQLite to work on anything less than a 32-bit processor. D. Richard Hipp" I was under the impression as long as the processor had enough room to hold the program (and RAM) it would work. The difference I would have expected would simply be

[sqlite] Porting into a microcontroller, minimum requirements

Hi, I was wondering if anyone has any basic guide lines on embedding SQLite into a microcontroller. For example, I am considering using an 8/16 bit processor with 1 MB flash, 1 MB SRAM and 2 GB data storage (SD card). Has anyone ported this before to an embedded system without an OS? Thanks,