Skip to content

Suggestions on improving SQLite storage backend performance #285

@justjake

Description

@justjake

Here's a few suggestions after reading the benchmark description on the docs website and doing a brief code-review of the sqlite backend after seeing such abysmal performance on the benchmark. Like, sqlite is going to be a slower backend than RocksDB but it doesn't have to be this much slower!

  1. Cache prepared statement objects with their connection, rather than re-creating them each transaction. Compiling text to SQLite's bytecode is not free. At least these are amortized for the duration of the transaction object lifetime, but for repetitive small transactions such as those in the pokec.rs benchmark, re-compiling the queries for each iteration adds massive overhead.
  2. Switch to WITHOUT ROWID table like this: CREATE TABLE cozo (...) WITHOUT ROWID. Since cozo uses SQLite as a KV store and doesn't use incremental BLOB IO, switching to WITHOUT ROWID table will remove some overhead. Right now the table uses two btrees: one btree indexes the key blob and maps to the ROWID, and then the actual table btree maps from rowid to the tuple. Switching to WITHOUT ROWID will remove the indirection and actually store the tuples in a btree by key. Docs: https://www.sqlite.org/withoutrowid.html

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions