Alex Chi Z.
Alex Chi Z.
Currently, RisingLight's explain interface is not really "explainable". There are some executors that... * Use Rust's default `std::fmt::Debug` when explaining * Doesn't print out all information * Output too long...
Roadmap v0.2
In v0.2, we focus on sorting everything -- from the composite sort key and primary key indexing in storage layer, to sort merge executors in executor layer, to composite key...
Now we use buffered I/O, which might make benchmarking inaccurate. - [ ] Align blocks in column builder - [ ] Support direct I/O in column reader
related: https://github.com/risinglightdb/risinglight/issues/638
If we find distinct value statistics is very small compared with row counts, we can use RLE encoding when building RowSets. https://github.com/risinglightdb/risinglight/blob/65372ee4da36bada718a6ab00cdba865ba554e5e/src/storage/secondary/compactor.rs#L93-L96
Currently, we have create_dir, etc. everywhere. We'd better have a single interface to operate files on disk, so as to support in-memory / disk / object store backends.
https://github.com/risinglightdb/risinglight/pull/651 has introduced some dead code. We should clean up.
After https://github.com/risinglightdb/risinglight/pull/644 gets implemented, our storage layer would have range scan capability! To make SQL leverage this property, we can have a range filter scan rule, which does the following:...
We can have a struct like `PlanBase`, which is included in all optimizer plan nodes. Then, we can have `sorted` inside, along with the sort keys (e.g. `struct PlanBase {...
Currently, our catalog cannot handle the case for composite primary key. For example, ``` create table t1 (x int not null, y int not null, primary key(x, y)); create table...