Pekka Enberg ae47665a25 Merge 'Add support for DELETE query planning ' from Kim Seon Woo
### Purpose of this PR
Support for DELETE query execution planning
### Implementation Details
The main entry point for planning DELETE queries is the
`translate_delete` function. It is composed of three primary steps:
- `prepare_delete_plan`:
  - Reuses the existing SELECT query's WHERE clause parsing logic to
interpret and construct the initial delete plan.
- `optimize_delete_plan`:
  - eliminating BETWEEN expressions
  - usage of indexes
- `emit_program_for_delete`:
  - Add instructions for delete operation
I've tried to reuse existing logic(mostly on SELECT operations) as much
as I can, so that we can automatically incorporate new changes
automatically.
### Delete planning debug
I've used `println!(...)` to specify the rows to delete. Example below
<img width="374" alt="image" src="https://github.com/user-
attachments/assets/f109e1c6-6b69-43b9-bb23-4bee3a835767" />
### Bytecode compatibility
`EXPLAIN DELETE FROM users WHERE id = 1;`
<img width="1724" alt="image" src="https://github.com/user-
attachments/assets/ce2995d7-6947-493e-ad3d-224df7f4e7c2" />
`EXPLAIN DELETE FROM users WHERE id > 3`
<img width="1726" alt="image" src="https://github.com/user-
attachments/assets/ac516bd2-fe80-44c5-9a4b-8e35d574c47d" />
`EXPLAIN DELETE FROM users WHERE id < 3`
<img width="1711" alt="image" src="https://github.com/user-
attachments/assets/29d0ccba-c373-483e-bb6b-9344289cae02" />
### TODO(future works)
- Add support for `Clear` opcode
- Add test when `delete` is implemented in `Cursor`
<img width="1728" alt="image" src="https://github.com/user-
attachments/assets/28d371fc-90f5-42e5-8add-d5218f830234" />

Closes #538
2024-12-27 18:34:02 +02:00
2024-12-18 16:43:35 +01:00
2024-12-27 10:20:41 +02:00
2024-12-27 10:55:29 +02:00
2024-12-12 17:22:03 +01:00
2024-12-25 11:54:16 +02:00
2024-12-27 10:20:41 +02:00
2024-12-27 10:20:41 +02:00
2024-12-27 10:20:41 +02:00
2024-12-26 15:08:11 -08:00
2024-11-15 15:55:33 +02:00
2024-12-14 17:13:02 +02:00
2024-12-25 11:54:16 +02:00
2024-12-21 13:19:04 +05:30
2024-12-18 20:45:55 +02:00
2024-12-26 15:08:11 -08:00
2024-05-07 16:33:44 -03:00
2024-07-05 09:51:56 +03:00
2024-12-20 09:22:44 +02:00
2024-07-12 13:07:34 -07:00
2024-07-12 12:38:56 -07:00
2024-12-14 11:36:22 +02:00

Limbo

Limbo

Limbo is a work-in-progress, in-process OLTP database management system, compatible with SQLite.

Build badge MIT Discord


Features

  • In-process OLTP database engine library
  • Asynchronous I/O support on Linux with io_uring
  • SQLite compatibility (status)
    • SQL dialect support
    • File format support
    • SQLite C API
  • JavaScript/WebAssembly bindings (wip)
  • Support for Linux, macOS, and Windows

Getting Started

CLI

Install limbo with:

curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/penberg/limbo/releases/latest/download/limbo-installer.sh | sh

Then use the SQL shell to create and query a database:

$ limbo database.db
Limbo v0.0.6
Enter ".help" for usage hints.
limbo> CREATE TABLE users (id INT PRIMARY KEY, username TEXT);
limbo> INSERT INTO users VALUES (1, 'alice');
limbo> INSERT INTO users VALUES (2, 'bob');
limbo> SELECT * FROM users;
1|alice
2|bob

JavaScript (wip)

Installation:

npm i limbo-wasm

Example usage:

import { Database } from 'limbo-wasm';

const db = new Database('sqlite.db');
const stmt = db.prepare('SELECT * FROM users');
const users = stmt.all();
console.log(users);

Python (wip)

pip install pylimbo

Example usage:

import limbo

con = limbo.connect("sqlite.db")
cur = con.cursor()
res = cur.execute("SELECT * FROM users")
print(res.fetchone())

Developing

Build and run limbo cli:

cargo run --package limbo --bin limbo database.db

Run tests:

cargo test

Test coverage report:

cargo tarpaulin -o html

Run benchmarks:

cargo bench

Run benchmarks and generate flamegraphs:

echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
cargo bench --bench benchmark -- --profile-time=5

FAQ

How is Limbo different from libSQL?

Limbo is a research project to build a SQLite compatible in-process database in Rust with native async support. The libSQL project, on the other hand, is an open source, open contribution fork of SQLite, with focus on production features such as replication, backups, encryption, and so on. There is no hard dependency between the two projects. Of course, if Limbo becomes widely successful, we might consider merging with libSQL, but that is something that will be decided in the future.

Publications

  • Pekka Enberg, Sasu Tarkoma, Jon Crowcroft Ashwin Rao (2024). Serverless Runtime / Database Co-Design With Asynchronous I/O. In EdgeSys 24. [PDF]
  • Pekka Enberg, Sasu Tarkoma, and Ashwin Rao (2023). Towards Database and Serverless Runtime Co-Design. In CoNEXT-SW 23. [PDF] [Slides]

Contributing

We'd love to have you contribute to Limbo! Check out the contribution guide to get started.

License

This project is licensed under the MIT license.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Limbo by you, shall be licensed as MIT, without any additional terms or conditions.

Description
No description provided
Readme 43 MiB
Languages
Rust 76.8%
Tcl 6.6%
C 6.4%
Dart 2.4%
Java 2.3%
Other 5.3%