Instead of using static elements, use a dynamically generated DBSP-
circuit to keep views.
The DBSP circuit is generated from the logical plan, which only supports
enough for us to generate the DBSP circuit at the moment.
The state of the view is still kept inside the IncrementalView, instead
of materialized at the operator level. As a consequence, this still
depends on us always populating the view at startup. Fixing this is the
next step.
Closes#2815
This is implementation of #2801, basically repeating of `sqlite` output.
1. I do not want any bike-shedding, so I am totally fine with sqlite
version. For me it was mainly fun trying to work with Rust. On the other
hand, if it will be needed to do it somehow differently, than I am
totally fine with that. Even more fun :-)
2. I do not know where tests for this kind of things are, sorry. If
tests are needed and somebody can point to me to the place where they
can be found, I'll be more than happy to add them as well.
Currently, I can only show how it looks like this way:
```bash
> target/debug/tursodb -m records ../db1
Turso v0.1.4
Enter ".help" for usage hints.
This software is ALPHA, only use for development, testing, and experimentation.
turso> CREATE TABLE test(x INT, some_text TEXT, val DOUBLE);
turso> INSERT INTO test VALUES (100, "very important info", 23.12), (2, NULL, 3.14159265), (98, "yet another very important and long text record", NULL);
turso> SELECT * FROM test;
x = 100
some_text = very important info
val = 23.12
x = 2
some_text =
val = 3.14159265
x = 98
some_text = yet another very important and long text record
val =
```
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2835
```
Benchmarking Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...: Collecting 100 samples in estimated 5.008
Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...
time: [4.0081 µs 4.0223 µs 4.0364 µs]
change: [-2.9298% -2.2538% -1.6786%] (p = 0.00 < 0.05)
Performance has improved.
```
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2847
It's a hot instruction for TPC-H, for example, so worth optimizing.
Reduces op_zero_or_null() from 5.6% to 2.4% in CPU flamegraph for TCP-H
Q1.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2842
This adds support for "OFF" and "FULL" (default) synchronous modes. As
future work, we need to add NORMAL and EXTRA as well because
applications expect them.
Closes#2833
I think the `try_into()` is probably expensive. we can use the fact that
both interior page types are `<=5` to our advantage for a little perf
boost in these hot path function calls
Based on #2836 (just to see aggregate perf difference in benchmarks)
Closes#2837
it wasn't used for anything. no more `page.get().get().id`.
i did this simply to clean up the code (we haven't needed BTreePageInner
in probably at least 8 months or more?), but it also:
- makes practically every tpc-h query faster due to removing indirection
and refcell runtime borrowing every time the btree stack is accessed etc
- makes every SELECT * FROM users bench query faster
- drops the count() benchmark runtime by like half
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2836
- check free list trunk and pages
- use shared hash map to check for duplicate references for pages
- properly check overflow pages
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2816
This adds support for "OFF" and "FULL" (default) synchronous modes. As
future work, we need to add NORMAL and EXTRA as well because
applications expect them.
The removed comment no longer matches the current code. The
OrderByRemapping struct and the surrounding comments are sufficient to
explain deduplication and remapping.
I added `IOContext` to `DatbaseStorage` IO trait and this struct will
carry the necessary ctx required for encryption (or checksums.). This
lets us set the encryption at outside and let the IO layer handle it
properly
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#2812
