mirror of
https://github.com/tursodatabase/limbo.git
synced 2025-12-23 08:21:09 +00:00
7948259d37
Some checks are pending
Build and push limbo-sim image / deploy (push) Waiting to run
C compat Tests / test (push) Waiting to run
Dart/Flutter / precompile (blacksmith-4vcpu-ubuntu-2404) (push) Waiting to run
Dart/Flutter / precompile (macOS-latest) (push) Waiting to run
Dart/Flutter / test (windows-latest) (push) Waiting to run
Dart/Flutter / publish (push) Waiting to run
Dart/Flutter / test (blacksmith-4vcpu-ubuntu-2404) (push) Waiting to run
Dart/Flutter / precompile (windows-latest) (push) Waiting to run
Java Tests / test (push) Waiting to run
Run long fuzz tests and stress test / run-long-tests (push) Waiting to run
Run long fuzz tests and stress test / simple-stress-test (push) Waiting to run
Build & publish @tursodatabase/database / db-bindings-aarch64-apple-darwin - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / db-bindings-aarch64-unknown-linux-gnu - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / db-bindings-wasm32-wasip1-threads - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / db-bindings-x86_64-pc-windows-msvc - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / db-bindings-x86_64-unknown-linux-gnu - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / sync-bindings-aarch64-apple-darwin - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / sync-bindings-aarch64-unknown-linux-gnu - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / sync-bindings-wasm32-wasip1-threads - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / sync-bindings-x86_64-pc-windows-msvc - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / sync-bindings-x86_64-unknown-linux-gnu - node@20 (push) Waiting to run
Build & publish @tursodatabase/database / Test DB bindings on Linux-x64-gnu - node@20 (push) Blocked by required conditions
Build & publish @tursodatabase/database / Test DB bindings on browser@20 (push) Blocked by required conditions
Build & publish @tursodatabase/database / Publish (push) Blocked by required conditions
Python / configure-strategy (push) Waiting to run
Python / test (push) Blocked by required conditions
Python / lint (push) Waiting to run
Python / linux (x86_64) (push) Waiting to run
Python / macos-arm64 (aarch64) (push) Waiting to run
Python / sdist (push) Waiting to run
Python / Release (push) Blocked by required conditions
Rust / clippy (push) Waiting to run
Rust / cargo-fmt-check (push) Waiting to run
Rust / build-native (blacksmith-4vcpu-ubuntu-2404) (push) Waiting to run
Rust / build-native (macos-latest) (push) Waiting to run
Rust / build-native (windows-latest) (push) Waiting to run
Rust Benchmarks+Nyrkiö / tpc-h-criterion (push) Waiting to run
Rust Benchmarks+Nyrkiö / tpc-h (push) Waiting to run
Rust Benchmarks+Nyrkiö / vfs-bench-compile (push) Waiting to run
Rust / simulator (push) Waiting to run
Rust / test-limbo (push) Waiting to run
Rust / test-sqlite (push) Waiting to run
Rust Benchmarks+Nyrkiö / bench (push) Waiting to run
Rust Benchmarks+Nyrkiö / clickbench (push) Waiting to run
Made a new PR based on @sivukhin 's PR #2869 that had a lot of conflicts. You can check out the PR description from there. ## The main idea is: Before, if we had an index on `x` and had a query like `WHERE x > 100 and x < 200`, the plan would be something like: ``` - Seek to first row where x > 100 - Then, for every row, discard the row if x >= 200 ``` This is highly wasteful in cases where there are a lot of rows where `x >= 200`. Since our index is sorted on `x`, we know that once we hit the _first_ row where `x >= 200`, we can stop iterating entirely. So, the new plan is: ``` - Seek to first row where x > 100 - Then, iterate rows until x >= 200, and then stop ``` This also improves the situation for multi-column indexes. Imagine index on `(x,y)` and a condition like `WHERE x = 100 and y > 100 and y < 200`. Before, the plan was: ``` - Seek to first row where x=100 and y > 100 - Then, iterate rows while x = 100 and discard the row if y >= 200 - Stop when x > 100 ``` This also suffers from a problem where if there are a lot of rows where `x=100` and `y >= 200`, we go through those rows unnecessarily. The new plan is: ``` - Seek to first row where x=100 and y > 100 - Then, iterate rows while x = 100 and y < 200 - Stop when either x > 100 or y >= 200 ``` Which prevents us from iterating rows like `x=100, y = 666` unnecessarily because we know the index is sorted on `(x,y)` - once we hit any row where `x>100` OR `x=100, y >= 200`, we can stop. Closes #3644 |
||
|---|---|---|
| .. | ||
| cli_tests | ||
| javascript | ||
| sqlite3 | ||
| sqlite_test_ext | ||
| test_files | ||
| unreliable-libc | ||
| wal | ||
| affinity.test | ||
| agg-functions.test | ||
| all.test | ||
| alter_column.test | ||
| alter_table.test | ||
| analyze.test | ||
| attach.test | ||
| autoincr.test | ||
| boolean.test | ||
| changes.test | ||
| cmdlineshell.test | ||
| coalesce.test | ||
| collate.test | ||
| compare.test | ||
| concat.test | ||
| create_index.test | ||
| create_table.test | ||
| default_value.test | ||
| delete.test | ||
| drop_index.test | ||
| drop_table.test | ||
| foreign_keys.test | ||
| gen-bigass-database.py | ||
| gen-database.py | ||
| glob.test | ||
| groupby.test | ||
| insert.test | ||
| integrity_check.test | ||
| join.test | ||
| json.test | ||
| like.test | ||
| literal.test | ||
| materialized_views.test | ||
| math.test | ||
| null.test | ||
| offset.test | ||
| orderby.test | ||
| partial_idx.test | ||
| pragma.test | ||
| pyproject.toml | ||
| README.md | ||
| rollback.test | ||
| scalar-functions-datetime.test | ||
| scalar-functions-printf.test | ||
| scalar-functions.test | ||
| select.test | ||
| subquery.test | ||
| tester.tcl | ||
| testing.db | ||
| testing_norowidalias.db | ||
| testing_small.db | ||
| testing_user_version_10.db | ||
| time.test | ||
| total-changes.test | ||
| transactions.test | ||
| update.test | ||
| upsert.test | ||
| values.test | ||
| vector.test | ||
| views.test | ||
| vtab.test | ||
| where.test | ||
| window.test | ||
Turso Testing
Testing Extensions
When adding tests for extensions, please follow these guidelines:
- Tests that verify the internal logic or behavior of a particular extension should go into
cli_tests/extensions.py. - Tests that verify how extensions interact with the database engine, such as virtual table handling, should be written
in TCL (see
vtab.testas an example).
To check which extensions are available in TCL, or to add a new one, refer to the tester.tcl file and look at the extension_map.