Re: [sqlite] large table performance

2006-03-03 Thread drh
"Daniel Franke" <[EMAIL PROTECTED]> wrote: >> > Another question that arose today: > Is there any penalty for switching tables during INSERTs within the > same COMMIT? E.g. > > BEGIN; > INSERT INTO tableA VALUES ...; > INSERT INTO tableB VALUES ...; > INSERT INTO tableA VALUES

Re: [sqlite] large table performance

2006-03-03 Thread Elrond
While talking performance: Did anyone compare sqlite in a simplistic CREATE TABLE t(key BLOB PRIMARY KEY, value BLOB); scenario to other dedicated key/value DBs (like berkeley deb, gdbm, ...)? Elrond

Re: [sqlite] large table performance

2006-03-03 Thread drh
Daniel Franke <[EMAIL PROTECTED]> wrote: > > Is there any chance to speed this up? > > CREATE TABLE genotypes( > markerid integer NOT NULL REFERENCES marker(id), > individualid integer NOT NULL REFERENCES individuals(id), > genA integer, > genB integer, > UNIQUE(markerid,

RE: [sqlite] large table performance

2006-03-03 Thread Brandon, Nicholas (UK)
>Given the schema below, feeding a million INSERTs into the database by >sqlite3_exec() takes about 30 minutes (this includes transactions, indices >and "PRAGMA synchronous=off" as well as a fully optimized build of sqlite). >Is there any chance to speed this up? Production datasets could

Re: [sqlite] large table performance

2006-03-03 Thread Bogusław Brandys
Daniel Franke wrote: Hi all. I spent the last days bragging that a single database file as provided by sqlite is a far better approach to store data than -literally- thousands of flat files. Now, I got a small amount of testing data an wow ... I'm stuck. Area: Bioinformatics. Imagine a