feat(test): add sqlplannertest

CONTRIBUTING.md

@@ -55,6 +55,8 @@ At the same time, developers may also add end-to-end tests with sqllogictest. Yo
 `tests/sql` and write sqllogictest to run SQLs in RisingLight and to verify implementation correctness.
 All the files suffix with `.slt` but not prefix with `_` in `tests/sql` will be automatically included in the end-to-end tests.
 
+See [SQLLogicTest and SQLPlannerTest](docs/05-e2e-tests.md) for more information.
+
 You'll need `cargo install cargo-nextest` to run tests.
 
 ## Running Test and Checks

Cargo.toml

@@ -84,7 +84,8 @@ lto = 'thin'
 [workspace]
 members = [
   "proto",
-  "tests/sqllogictest"
+  "tests/sqllogictest",
+  "tests/sqlplannertest"
 ]
 
 [patch.crates-io]

Makefile

@@ -26,6 +26,9 @@ test:
 
 check: fmt_check clippy_check build test docs_check
 
+apply_planner_test:
+	cargo run -p risinglight_plannertest --bin apply-planner-test
+
 clean:
 	cargo clean
 	rm -rf $(TPCH_DBGEN_PATH)

docs/05-e2e-tests.md

@@ -0,0 +1,51 @@
+# SQLLogicTest and SQLPlannerTest
+
+RisingLight uses two test frameworks to do end-to-end tests.
+
+## SQLLogicTest
+
+SQLLogicTest will run a special `slt` file and compare the result from the expected output.
+The test cases are stored under `tests/sql` folder.
+
+For example, let's see `order_by.slt`:
+
+```
+statement ok
+create table t(v1 int not null, v2 int not null)
+
+statement ok
+insert into t values(1, 1), (4, 2), (3, 3), (10, 12), (2, 5)
+
+query I
+select v1 from t order by v1 asc
+----
+1
+2
+3
+4
+10
+```
+
+The first 3 test cases of this test file are
+* check whether create table works
+* check whether insert table works 
+* select data from table
+
+We use `statement ok` to ensure statement successfully runs, and `query` to compare the query result.
+
+When running `make test`, the test runner will run all files under `tests/sql` folder.
+
+## SQLPlannerTest
+
+SQLPlannerTest is a regression test. We will write yaml files to describe the cases we want to test.
+The test cases are stored in `tests/planner_test`. Use the following command:
+
+```
+make apply_planner_test
+```
+
+to generate a sql file containing explain results for each yaml file.
+
+Generally, we will compare the explain result before and after a commit, so as to know how the commit
+affects the optimizer result. We don't really care about the correctness -- we just compare the explain
+result before and after a PR.

src/storage/error.rs

@@ -76,7 +76,7 @@ impl From<Arc<TracedStorageError>> for TracedStorageError {
 
 /// [`StorageResult`] with backtrace.
 #[derive(Error)]
-#[error("{source:?}\n{backtrace:#}")]
+#[error("{source:?}\n{backtrace}")]
 pub struct TracedStorageError {
     #[from]
     source: StorageError,

src/storage/secondary/delete_vector.rs

@@ -3,6 +3,7 @@
 use std::path::Path;
 
 use bitvec::prelude::BitVec;
+use futures::pin_mut;
 use itertools::Itertools;
 use prost::Message;
 use risinglight_proto::rowset::DeleteRecord;
@@ -42,9 +43,10 @@ impl DeleteVector {
     }
 
     pub async fn write_all(
-        file: &mut tokio::fs::File,
+        file: impl tokio::io::AsyncWrite,
         deletes: &[DeleteRecord],
     ) -> StorageResult<()> {
+        pin_mut!(file);
         let mut data = Vec::new();
         for delete in deletes {
             delete.encode_length_delimited(&mut data)?;