*** 5,20 ****
the SQLite source tree and recompile. All tables created will be "in-memory".
The filename supplied to sqlite_open is ignored.
! The following problems currently exist: {linebreak}
! * Virtually no testing done. All of the SQLite test suite that is practical to
! run with in-memory tables succeeds however. {linebreak}
! * No memory-leak testing has been done. {linebreak}
! * In some queries (ie. to process ORDER BY clauses and some sub-selects),
SQLite uses binary-trees to hold intermediate data. The btree layer should not
bother to store rollback information in these cases (but it currently does).
! {linebreak}
! * It's a compile time thing. It would be better if you could choose to create
! tables in-memory at run-time. {linebreak}
The speedcompare.tcl script is a dodgy modification of DRH's speedcompare.tcl
script. You run it using the "tclsqlite" interpreter.
--- 5,19 ----
the SQLite source tree and recompile. All tables created will be "in-memory".
The filename supplied to sqlite_open is ignored.
! The following problems currently exist:
! *: Virtually no testing done. All of the SQLite test suite that is practical to
! run with in-memory tables succeeds however.
! *: No memory-leak testing has been done.
! *: In some queries (ie. to process ORDER BY clauses and some sub-selects),
SQLite uses binary-trees to hold intermediate data. The btree layer should not
bother to store rollback information in these cases (but it currently does).
! *: It's a compile time thing. It would be better if you could choose to create
! tables in-memory at run-time.
The speedcompare.tcl script is a dodgy modification of DRH's speedcompare.tcl
script. You run it using the "tclsqlite" interpreter.
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|