*** 1,29 ****
This page is about using in-memory SQLite databases.
- The file btree_rb.c attached to this page is a replacement binary-tree layer.
- It uses "red-black" binary trees. To use it, copy it over the btree.c file in
- 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.
-
- The speed.txt file contains performance stats comparing in-memory with on-disk
- tables.
-
- If anyone wants to develop this into a proper patch for SQLite and has any
- questions on how to do this, or if you find any bugs, please post to the SQLite
- yahoo group.
----
2003-04-15: The in-memory database is now in the CVS tree, though it is still
mostly untested.
--- 1,5 ----
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|