Currently, this is effectively a no-op because, at the optimization
stage, window function expressions are in the form
win_func(subquery_column1, subquery_column2, ...).
Nevertheless, expressions are rewritten to maintain consistency with
aggregates, which also hold cloned expressions from sources like result
columns. This ensures future changes in the optimizer won’t break window
function handling.
Adds initial support for window functions. For now, only existing
aggregate functions can be used as window functions—no specialized
window-specific functions are supported yet.
Currently, only the default frame definition is implemented:
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW EXCLUDE NO OTHERS.
Two main reasons for this change:
* Improve readability by moving the logic for this special case closer
to the code that relies on it.
* Decouple AggFunc from the Aggregate struct. In the future, window
function processing will use AggFunc directly, without necessarily
depending on Aggregate.
Previously, while resetting accumulator registers, we would also
reset subsequent registers. This happened because the number of registers
to reset was computed as the sum of arguments rather than the number of
aggregate functions.
Adds the AggValue instruction, which computes the current aggregate
result and writes it to a dedicated destination register.
Unlike AggFinal, it does not overwrite or clear the accumulator
register. This makes it possible to retrieve aggregate results multiple
times—needed when processing window functions—while preserving the
accumulator state.
Previously, only the External and Avg aggregates mutated state during
AggFinal. This is unnecessary because AggFinal runs only once per group,
so caching the result provides no performance benefit.
By avoiding state mutation, we can also reuse op_agg_final for the
AggValue instruction that will be added soon.
## Problem
When a delete replaces an index interior cell, the replacement key is LT
the deleted key. Currently on the main branch, after the deletion
happens, the following call to BTreeCursor::next() stops at the replaced
interior cell.
This is incorrect - imagine the following sequence:
- We are executing a query that deletes all keys WHERE key > 5
- We delete <key=6> from an interior node, and take a replacement
<key=5> from the left subtree of that interior page
- next() is called, and we land on the interior node again, which now
has <key=5>, and we incorrectly delete it even though our WHERE
condition is key > 5.
## Solution
This PR:
- Tracks `interior_node_was_replaced` in CheckNeedsBalancing
- If no balancing is needed and a replacement occurred, advances once so
the next invocation of next() will skip the replaced cell properly
i.e. we prevent next() from landing on the replaced content and ensures
iteration continues with the next logical record.
## Details
This problem only became apparent once we started using indexes as valid
iteration cursors for DELETE operations in #2981Closes#3045
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3049
The transaction upgrade logic in Transaction opcode is total nonsense
for concurrent transactions so just drop it.
Fixes#3061
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#3070
Fixes#1817, #2068, #1326, #1397.
The solution is very much not ideal, but fixes all math function related
incompatibilities.
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3033
After this PR:
```
turso> EXPLAIN QUERY PLAN SELECT 1;
QUERY PLAN
`--SCAN CONSTANT ROW
turso> EXPLAIN QUERY PLAN SELECT 1 UNION SELECT 1;
QUERY PLAN
`--COMPOUND QUERY
|--LEFT-MOST SUBQUERY
| `--SCAN CONSTANT ROW
`--UNION USING TEMP B-TREE
`--SCAN CONSTANT ROW
turso> CREATE TABLE x(y);
turso> CREATE TABLE z(y);
turso> EXPLAIN QUERY PLAN SELECT * from x,z;
QUERY PLAN
|--SCAN x
`--SCAN z
turso> EXPLAIN QUERY PLAN SELECT * from x,z ON x.y = z.y;
QUERY PLAN
|--SCAN x
`--SEARCH z USING INDEX ephemeral_z_t2
turso>
```
Closes#3057
Using this epoch that gets incremented on each checkpoint, combined with
snapshotting the page, allows us to use cached pages during even passive
mode (without the write lock), because we check again after the snapshot
that the page is still valid.
https://github.com/tursodatabase/turso/pull/3053#issuecomment-3285093103
This PR also removes the `WalFile` copy of the `WalHeader`, to prevent
us forgetting that it exists and using potentially stale data, and adds
`checkpoint_seq` atomic to WalFile to help us determine whether the log
has changed and a read tx snapshot is stale.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3058
This was causing checkpoint_seq to be 0 when we had already successfully
ran a passive checkpoint, and causing us to use improper pages from the
cache.
Fast balancing routine for the common special case where the rightmost
leaf page of a given subtree overflows such that the overflowing cell
would be the rightmost cell on the page -- i.e. an append. In this case
we just add a new leaf page as the right sibling of that page, put the
overflow cell there, and insert a new divider cell into the parent. The
high level steps are:
1. Allocate a new leaf page and insert the overflow cell payload in it.
2. Create a new divider cell in the parent - it contains the page number
of the old rightmost leaf, plus the largest rowid on that page.
3. Update the rightmost pointer of the parent to point to the new leaf
page.
4. Continue balance from the parent page (inserting the new divider cell
may have overflowed the parent
Closes#3041
…lite/wal
This is considerably simpler with 1 thread as we just try to yield
control when I/O happens and we only run io.run_once when all
connections tried to do some work. This allows connections to
cooperatively progress.
Closes#3060
Flushing mvcc changes to disk requires serialization. To do so we simply
introduce a lock for pager.end_tx, which will take ownership of flushing
to WAL. Once this is finished we can simply release lock.
When multiple tx writes happen concurrently in mvcc, max frame will be
updated. This new max_frame makes is the point of view of the other
transaction return busy because his current wal snapshot is outdated.
Closes#3059
This is considerably simpler with 1 thread as we just try to yield
control when I/O happens and we only run io.run_once when all
connections tried to do some work. This allows connections to
cooperatively progress.
Flushing mvcc changes to disk requires serialization. To do so we simply
introduce a lock for pager.end_tx, which will take ownership of flushing
to WAL. Once this is finished we can simply release lock.
When multiple tx writes happen concurrently in mvcc, max frame will be
updated. This new max_frame makes is the point of view of the other
transaction return busy because his current wal snapshot is outdated.
Intel MAC builds were removed in https://github.com/tursodatabase/turso/
commit/3547bd10931e030a372bedb4968404301c2936c6 but arm builds were
broken after that.
This PR returns back proper ARM builds for Apple
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3054
This tries to establish smooth as possible experience for browser
packages in web.
In order to do that this PR do the following tricks:
1. export `./vite` entry-point which should be used like `import {
connect } from "@tursodatabase/database-browser/vite"` for Vite bundler
* This entrypoint has fix for the issue
https://github.com/vitejs/vite/issues/8427 which breaks package in the
dev-server mode
* In order to overcome this we do 2 tricks:
- Inline WASM module in order to avoid loading it from the separate
file
- Use same file as entry-point for main thread and for the web
worker
* Note, that we do these tricks only for `development` build and
produce build will be chunked and optimized as usual with Vite and will
treat worker and WASM modules as separate fiels
3. export `./turbopack` entry-point which should be used like `import {
connect } from @tursodatabase/database-browser/turbopack"` for Turbopack
(Next.js) bundler
* This entrypoint has fix for the issue
https://github.com/vercel/next.js/issues/82520'
* In order to overcome this for now we always inline WASM for Next.js
4. Bundle browser libraries in order to easily consume them without need
for bundlers:
* e.g. `import { connect } from
"https://unpkg.com/@tursodatabase/database-browser/bundle/main.es.js";`
5. We vendor `@napi-rs/wasm-runtime` for now in order to fix runtime
errors due to accesses to `process.env.NODE_DEBUG_NATIVE` env var (not
defined in web)
* This should be very temporary solution because I already fixed
wasm-util dependency which cause this error
(https://github.com/toyobayashi/wasm-util/issues/4) and hope that napi-
rs PR will be merged soon: https://github.com/napi-rs/napi-rs/pull/2921
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3017
