Thanks everyone, I cannot apply all the suggestions (for example I do
use foreign keys), but probably I can improve the performance of the
calculations.
On Sat, Apr 27, 2013 at 6:48 AM, David King wrote:
>> The idea of temporary tables in-memory is nice, but I do not know
> The idea of temporary tables in-memory is nice, but I do not know how
> to apply it.
> I see in the documentation I can use the TEMP in CREATE TABLE, but I am not
> sure of the effect.
> Does it mean that the table is created in memory and it is lost in
> sqlite3_close?
There are a few things
On 27 Apr 2013, at 2:21am, Paolo Bolzoni wrote:
> The idea of temporary tables in-memory is nice, but I do not know how
> to apply it.
> I see in the documentation I can use the TEMP in CREATE TABLE, but I am not
> sure of the effect.
Temporary tables are a
The idea of temporary tables in-memory is nice, but I do not know how
to apply it.
I see in the documentation I can use the TEMP in CREATE TABLE, but I am not
sure of the effect.
Does it mean that the table is created in memory and it is lost in
sqlite3_close?
On Fri, Apr 26, 2013 at 8:07 PM,
auto_vacuum Turn off autovacuum and just run it yourself when you're idle
foreign_keys Turn off foreign keys checks (or just don't use foreign keys)
ignore_check_constraints Same
journal_mode OFF might actually be faster than MEMORY, but disables rollback
support
locking_mode EXCLUSIVE can be
The subject pretty much says it all, I use sqlite3 as a way to save
temporary results from a calculation.
In this context I do not care about safety of the data. If the program
fails or there is a blackout I will just delete the sqlite3 file, eventually
fix the bug, and restart.
At the moment I
6 matches
Mail list logo