Commit Graph

3407 Commits

Author SHA1 Message Date
Pekka Enberg
9ffc4767bb Merge 'fragment bench functions' from Pere Diaz Bou
Easier to run now with:
```
cargo bench -- "execute_select_rows/50"
```

Closes #1142
2025-03-19 19:01:46 +02:00
Pekka Enberg
52b546ff64 Add limbo_ext_tests to crates 2025-03-19 19:00:12 +02:00
Pekka Enberg
4a3cbd6fa3 Add limbo_completion to crates 2025-03-19 18:58:21 +02:00
Pere Diaz Bou
13d518d086 fragment bench functions 2025-03-19 17:55:24 +01:00
Pekka Enberg
d0deff2d8b github: Attempt to fix Python release workflow 2025-03-19 18:46:48 +02:00
Pekka Enberg
ddb39d2493 Limbo 0.0.17 2025-03-19 17:29:17 +02:00
Pekka Enberg
d4db5eb4c1 Merge 'Various JSON and JSONB function improvements' from Ihor Andrianov
Added jsonb_remove, jsonb_replace, json_replace.
Updated json_remove to use jsonb under the hood.
Fixed json function big numbers serialization.
Add tests for new functions.

Closes #1140
2025-03-19 17:21:44 +02:00
Ihor Andrianov
f42b62f43c update compat for json functions 2025-03-19 13:00:55 +02:00
Ihor Andrianov
ca0be110ec fix big number parsing for json functions 2025-03-19 12:53:34 +02:00
Ihor Andrianov
62916f3a97 cargo clippy 2025-03-19 11:59:20 +02:00
Ihor Andrianov
32ea972151 make tests pass 2025-03-19 11:29:46 +02:00
Ihor Andrianov
bf649f98be add tests 2025-03-19 11:29:23 +02:00
Ihor Andrianov
b5e86a9e36 remove and replace functions defenitions 2025-03-18 21:43:48 +02:00
Ihor Andrianov
779e2c9e97 high order functions for remove and replace 2025-03-18 21:43:14 +02:00
Ihor Andrianov
403d0e8c21 implemented remove and replace in jsonb struct 2025-03-18 21:42:27 +02:00
Pekka Enberg
76887af59e Merge 'Fix read completion error in VFS' from Preston Thorpe
Closes #1126
2025-03-18 20:18:48 +02:00
Pekka Enberg
a2c6831f30 Merge 'Implement FastLock for DatabaseHeader' from Pere Diaz Bou
The motivation behind implementing our own lock is to not depend on any
dependency as we should moving forward. This is a experiment for now as
a single test obviously is not enough but I believe this is the right
direction to on.
## benchmark tldr;
Execute benchmarks have a performance improvement around [1.78%, 7.5%]
which seems like it went okay as it was expected from removing
`pthread_mutex` calls.
## benchmarks before
```
Prepare `SELECT 1`/Limbo/SELECT 1
                        time:   [575.63 ns 577.33 ns 580.07 ns]
                        change: [-1.3304% -0.8881% -0.4675%] (p = 0.00 < 0.05)
                        Change within noise threshold.

Prepare `SELECT * FROM users LIMIT 1`/Limbo/SELECT * FROM users LIMIT 1
                        time:   [1.2070 µs 1.2114 µs 1.2166 µs]
                        change: [-0.8670% -0.4084% -0.0252%] (p = 0.06 > 0.05)
                        No change in performance detected.

Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...
                        time:   [2.9845 µs 2.9895 µs 2.9951 µs]
                        change: [-3.0470% -2.6038% -2.1301%] (p = 0.00 < 0.05)
                        Performance has improved.
Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou... #2
                        time:   [1.6015 µs 1.6084 µs 1.6157 µs]
                        change: [-0.0676% +0.3850% +0.8704%] (p = 0.11 > 0.05)
                        No change in performance detected.
Execute `SELECT * FROM users LIMIT ?`/Limbo/1
                        time:   [442.46 ns 446.72 ns 454.13 ns]
                        change: [+3.9744% +4.5337% +5.3357%] (p = 0.00 < 0.05)
                        Performance has regressed.
Execute `SELECT * FROM users LIMIT ?`/Limbo/10
                        time:   [3.1722 µs 3.1850 µs 3.1980 µs]
                        change: [+7.1994% +7.7452% +8.2856%] (p = 0.00 < 0.05)
                        Performance has regressed.
Execute `SELECT * FROM users LIMIT ?`/Limbo/50
                        time:   [14.976 µs 15.024 µs 15.078 µs]
                        change: [+5.7879% +6.2419% +6.7139%] (p = 0.00 < 0.05)
                        Performance has regressed.
Execute `SELECT * FROM users LIMIT ?`/Limbo/100
                        time:   [29.834 µs 29.925 µs 30.024 µs]
                        change: [+4.6519% +5.0384% +5.4491%] (p = 0.00 < 0.05)
                        Performance has regressed.
Execute `SELECT 1`/Limbo
                        time:   [45.135 ns 45.439 ns 45.763 ns]
                        change: [-0.4703% -0.0496% +0.3622%] (p = 0.81 > 0.05)
                        No change in performance detected.
```
## benchmarks after
```
Prepare `SELECT 1`/Limbo/SELECT 1
                        time:   [585.61 ns 590.92 ns 596.49 ns]
                        change: [+0.5902% +1.1505% +1.7012%] (p = 0.00 < 0.05)
                        Change within noise threshold.

Prepare `SELECT * FROM users LIMIT 1`/Limbo/SELECT * FROM users LIMIT 1
                        time:   [1.2061 µs 1.2090 µs 1.2119 µs]
                        change: [-0.2364% +0.0977% +0.4252%] (p = 0.57 > 0.05)
                        No change in performance detected.

Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...
                        time:   [2.9854 µs 2.9893 µs 2.9936 µs]
                        change: [-0.5752% -0.2529% +0.0167%] (p = 0.09 > 0.05)
                        No change in performance detected.
Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou... #2
                        time:   [1.5853 µs 1.5983 µs 1.6108 µs]
                        change: [-2.3810% -1.7986% -1.2748%] (p = 0.00 < 0.05)
                        Performance has improved.
Execute `SELECT * FROM users LIMIT ?`/Limbo/1
                        time:   [429.84 ns 431.34 ns 433.07 ns]
                        change: [-2.7721% -1.8504% -0.8738%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Execute `SELECT * FROM users LIMIT ?`/Limbo/10
                        time:   [2.9184 µs 2.9254 µs 2.9323 µs]
                        change: [-8.2377% -7.7816% -7.3373%] (p = 0.00 < 0.05)
                        Performance has improved.
Execute `SELECT * FROM users LIMIT ?`/Limbo/50
                        time:   [14.190 µs 14.229 µs 14.271 µs]
                        change: [-6.2034% -5.7858% -5.3552%] (p = 0.00 < 0.05)
                        Performance has improved.
Execute `SELECT * FROM users LIMIT ?`/Limbo/100
                        time:   [28.734 µs 28.856 µs 28.979 µs]
                        change: [-4.3640% -3.9462% -3.5492%] (p = 0.00 < 0.05)
                        Performance has improved.

Execute `SELECT 1`/Limbo
                        time:   [43.144 ns 43.237 ns 43.326 ns]
                        change: [-4.9417% -4.5554% -4.2030%] (p = 0.00 < 0.05)
                        Performance has improved.
```

Closes #1120
2025-03-18 13:44:16 +02:00
Pekka Enberg
f9d7834874 Merge 'Jsonb extract' from Ihor Andrianov
Made a jsonb traversal by json path.
Changed some ordinary json functions to use jsonb under the hood, so now
behavior of our json module more like sqlite.
Found and fixed some bugs on the way.

Closes #1135
2025-03-17 18:25:28 +02:00
Ihor Andrianov
2fb18b4177 update compat 2025-03-17 16:20:43 +02:00
Pekka Enberg
7fc61b7b3d sqlite3: Add trace logging to sqlite3_exec() 2025-03-17 16:17:18 +02:00
Pekka Enberg
f82b1169a9 Fix Mobibench instructions to use WAL mode 2025-03-17 16:12:25 +02:00
Pekka Enberg
9435bd2f48 Merge 'Implement BEGIN DEFERRED' from Diego Reis
As explained in [docs](https://sqlite.org/lang_transaction.html):
> "DEFERRED means that the transaction does not actually start until the
database is first accessed. Internally, the BEGIN DEFERRED statement
merely sets a flag on the database connection that turns off the
automatic commit that would normally occur when the last statement
finishes. This causes the transaction that is automatically started to
persist until an explicit COMMIT or ROLLBACK or until a rollback is
provoked by an error or an ON CONFLICT ROLLBACK clause. If the first
statement after BEGIN DEFERRED is a SELECT, then a read transaction is
started. Subsequent write statements will upgrade the transaction to a
write transaction if possible, or return SQLITE_BUSY. If the first
statement after BEGIN DEFERRED is a write statement, then a write
transaction is started. "
The transaction upgrade `read -> write` is already handled by the VDBE
in `Transaction`.
closes #1001

Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>

Closes #1133
2025-03-17 16:02:28 +02:00
Diego Reis
16396c57c7 Removes unnecessary clone 2025-03-17 10:06:14 -03:00
Diego Reis
250478fedf Implement deferred transactions
As explained in docs: https://sqlite.org/lang_transaction.html

"BEGIN DEFERRED statement merely sets a flag on the database connection that turns off the automatic commit that would normally occur when the last statement finishes."

The transaction upgrade (read -> write) is already handled by the VDBE
2025-03-17 10:01:00 -03:00
Diego Reis
2314e7f906 Improve explain output for Transaction bytecode.
It isn't SQLite compliant but it helps a lot, specially when the user doesn't know what each register means.
2025-03-17 09:50:22 -03:00
Pekka Enberg
51237b92bc Merge 'Fix AutoCommit for IO halting' from Diego Reis
IDK if I'm being naive here but it was the easiest way that I found to
handle it.
closes #1004

Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>

Closes #1129
2025-03-17 11:56:00 +02:00
Pere Diaz Bou
829888f886 hint spin loop 2025-03-17 10:23:58 +01:00
Pere Diaz Bou
00ab3d1c0c Fix ordering and implement Deref 2025-03-17 10:22:42 +01:00
Pere Diaz Bou
cbc46ce2fe use compare_exchange 2025-03-17 10:21:34 +01:00
Pere Diaz Bou
20f5ade95e Experiment with a custom Lock for database header 2025-03-17 10:21:34 +01:00
Pekka Enberg
fd8ea0179d Merge 'bindings/python: Update PyO3 dependency to 0.24.0' from Pekka Enberg
Closes #1131
2025-03-17 11:16:36 +02:00
Pekka Enberg
a81ed4a523 bindings/python: Update PyO3 dependency to 0.24.0 2025-03-17 10:58:33 +02:00
Preston Thorpe
a2aca1f747 Merge branch 'tursodatabase:main' into main 2025-03-16 21:47:20 -04:00
Diego Reis
590f90ad9a Fix AutoCommit handling of an ongoing halt checkpoint 2025-03-16 15:35:49 -03:00
Ihor Andrianov
328ebfcd9e clippy 2025-03-16 15:31:06 +02:00
Ihor Andrianov
23d7d82b6c add jsonb_extract function 2025-03-16 15:14:29 +02:00
Ihor Andrianov
a3a9376347 unblock some tests 2025-03-16 03:36:02 +02:00
Ihor Andrianov
a878738a1e Fix jsonb bug with unclosed string and two commas in a row 2025-03-16 03:27:40 +02:00
Ihor Andrianov
0b22fbd566 Add jsonb to json_valid 2025-03-16 03:26:08 +02:00
Ihor Andrianov
dc6342c0de Add jsonb impl to existing json functions where possible 2025-03-16 02:08:49 +02:00
Ihor Andrianov
e327707ac6 Fix json_path broken condition 2025-03-15 22:01:48 +02:00
Ihor Andrianov
353422a25c Add follow json path in jsonb 2025-03-15 22:00:12 +02:00
Pekka Enberg
9efcacc601 Merge 'Add jsonb bench and rewrite jsonb parser to use slice and cursor' from Ihor Andrianov
Added bench to see how far i am from SQLite. If ~~Cloude~~ I did benches
correct moving from iterator to slice and cursor gives crazy performance
bump where we are almost on par with SLQLite when we are not talking
about huge jsons, but i suspect SQLite do some trickery there.

Closes #1125
2025-03-15 08:49:49 +02:00
PThorpe92
8e4705d6c6 Fix read completion error in vfs 2025-03-14 18:08:49 -04:00
Ihor Andrianov
b366045cb7 Rewrite parser to use slice and cursor instead of iterator 2025-03-14 19:47:18 +02:00
Ihor Andrianov
37c2655b6f Add jsonb bench 2025-03-14 19:46:29 +02:00
Pekka Enberg
731fbaf3c7 Merge 'Jsonb implementation' from Ihor Andrianov
This PR implements a complete JSONB parser and serializer as current PR
draft looks stale.
Sorry for huge PR.
I've choose a recursive parsing approach because:
1. It's simpler to understand and maintain
2. It follows SQLite's implementation pattern, ensuring compatibility
3. It naturally maps to JSON's hierarchical structure
The implementation includes comprehensive test coverage for standard
JSON features and JSON5 extensions. All test cases pass successfully,
handling edge cases like nested structures, escape sequences, and
various number formats.
While the code is ready for review, I believe it would benefit from fuzz
testing in the future to identify any edge cases not covered by the
current tests.
Ready for review, proposals and feedback.

Closes #1114
2025-03-13 21:17:52 +02:00
Pekka Enberg
b1419ab434 Merge 'Initial pass on Virtual FileSystem extension module' from Preston Thorpe
This PR implements a `VFS` module for our extension library, allowing
extensions to be written that can introduce different I/O back-ends.
EDIT: there is an included plain external/sync vfs example for testing,
as mentioned in #996 they can be combined after they are both merged and
we can keep 1 extension crate just for testing that features can be
added to, without making a new extension just to test stuff.
This PR also adds the `.vfslist` dot command, and replaces the `--io`
CLI argument with `--vfs` to match sqlite.
In order to support building vfs modules at compile time, and to then
support opening a brand new db file using a staticly built-in extension
module, a new method was created `open_with_vfs` that will load any vfs
modules before a `Database` is created, and uses that `IO` to create the
initial file, and returns it: `Result<(Arc<dyn IO>, Arc<Database>)>`. in
keeping with the API of core.
When #1039 is merged, the vfs module can be specified in a query
parameter.

Closes #960
2025-03-13 21:16:52 +02:00
Pekka Enberg
9f641f17c6 Disable some B-Tree fuzzers
Fuzz testing is great for finding bugs, but until we fix the bugs,
failing CI runs out of the blue for unrelated PRs is not very
productive. Hopefully we can enable this soon again, but until then,
let's not fail the test suite all the time randomly.
2025-03-13 10:30:34 +02:00
PThorpe92
c638b64a59 Fix tests to use updated extension name 2025-03-12 21:55:50 -04:00