This is a bunch of prep work, then a small amount of actual caching.
This:
Splits out a trait for the cache.
Pulls the trait down into core.
Combines Schema and cache references into a trait object, Known.
Alters the paths into the algebrizer where we previously passed &Schema, instead passing Known.
In one spot, does the work to turn [:find ?v :where [29 1 ?v]] into SELECT $v0 LIMIT 1 instead of SELECT datoms00.v FROM datoms datoms00 WHERE datoms00.a = 1 AND datoms00.e = 29.
It turns out that for a trivial database, it's quicker to retrieve the value from disk rather than take it as input, but (a) it should make a difference on bigger queries and data, and (b) the culmination of this work has us not run SQL at all.
Ignore the "Debug logging" commit; it's there so you can see log output when you run
cargo test --release test_cache_usage -- --nocapture
A small step after this is to (a) allow flipping cache on/off in the CLI, and (b) allow caching attributes from the CLI. That'll let us demo caching improvements interactively.
This is a bunch of prep work, then a small amount of actual caching.
This:
core
.Schema
and cache references into a trait object,Known
.&Schema
, instead passingKnown
.[:find ?v :where [29 1 ?v]]
intoSELECT $v0 LIMIT 1
instead ofSELECT datoms00.v FROM datoms datoms00 WHERE datoms00.a = 1 AND datoms00.e = 29
.It turns out that for a trivial database, it's quicker to retrieve the value from disk rather than take it as input, but (a) it should make a difference on bigger queries and data, and (b) the culmination of this work has us not run SQL at all.
Ignore the "Debug logging" commit; it's there so you can see log output when you run
A small step after this is to (a) allow flipping cache on/off in the CLI, and (b) allow caching attributes from the CLI. That'll let us demo caching improvements interactively.