The first rule of writing fast programs: don't use dynamic memory
allocation!
Brings `SELECT 1` micro-benchmark back to 70 ns, which is a bit closer
to what we had before.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#781
The first rule of writing fast programs: don't use dynamic memory
allocation!
Brings back some performance for the `SELECT 1` micro-benchmark,
although we're still not where we need to be.
The current status of the PR is halfway. The new framing of simulation
runner where `setup_simulation` is separated from `run_simulation`
allows for injecting custom plans easily. The PR is currently missing
the functionality to update the `SimulatorEnv` ad hoc from the plan, as
the environment tables were typically created during the planning phase.
The next steps will be to implement a function `fn
mk_env(InteractionPlan, SimulatorEnv) -> SimulatorEnv`, add `--load`
flag to the CLI for loading a serialized plan file, making a
corresponding environment and running the simulation.
We can optionally combine this with a `--save` option, in which we keep
a seed-vault as part of limbo simulator, corresponding each seed with
its generated plan and save the time to regenerate existing seeds by
just loading them into memory. I am curious to hear thoughts on this?
Would the maintainers be open to adding such a seed-vault? Do you think
the saved time would be worth the complexity of the approach?
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#720
This WIP driver uses the [purego](github.com/ebitengine/purego) library,
that supports cross platform `Dlopen`/`Dlsym` and not a whole lot else.
I really didn't want to use CGO, have very little experience with WASM
and I heard nothing but good things about this library. It's very easy
to use and stable especially when you consider the use case here of 3
functions.
NOTE: The WIP state that this PR is in right at this moment, is not able
to run these simple queries. This screengrab was taken from a couple
days ago when I wrote up a quick demo to load the library, call a simple
query and had it println! the result to make sure everything was working
properly.
I am opening this so kind of like the Java bindings, I can incrementally
work on this. I didn't want to submit a massive PR, try to keep them at
~1k lines max. The state of what's in this PR is highly subject and
likely to change.
I will update when they are at a working state where they can be tested
out and make sure they work across platforms.
Closes#776
This PR implements the strftime scalar function. It uses underneath the
hood chrono's strftime function and the already existent modifier logic.
The caveat of using chrono's strftime implementation is that it supports
some additional syntax that is not supported in sqlite, such as
precision modifiers (%.3f). If this is a deal breaker for this function
to be implemented at the moment, I will then write a strftime
implementation from scratch.
Closes#778
I think it is mostly correct, not so sure how to handle `BLOB`. One
thing that caught my attention is that sqlite seems to have a
optimization for trivial cases, saving some bytecodes, for instance:
I'm looking that right now.
Closes#777
This adds a separate push-only.yml workflow. For now pull request API
wasn't integrated yet, so shouldn't run on PRs.
disable cargo color
Fixes https://github.com/nyrkio/nyrkio/issues/304Closes#762
One of the discord links in the readme was pointing to a Chinese
discord. Both links are now pointing to Limbo's discord
Reviewed-by: Preston Thorpe (@PThorpe92)
Reviewed-by: Kim Seon Woo (@seonWKim)
Reviewed-by: Sonny (@sonhmai)
Closes#767
## The purpose of this PR
- Do not create a new `io` and instead use `io` which is used when
creating `LimboDatabase`.
- Run the loop of `step` function on the rust side(better for
performance as we don't have to switch between java <-> rust)
## Changes
- Java
- handle invalid cases
- remove @Disabled annotation from tests
- Rust
- add loops in the step function
## Reference
- https://github.com/tursodatabase/limbo/issues/615Closes#761
Take the logical OR of the values in register P1 and P2 and store the answer in register P3. If either P1 or P2 is nonzero (true) then the result is 1 (true) even if the other input is NULL. A NULL and false or two NULLs give a NULL output.
Take the logical AND of the values in registers P1 and P2 and write the result into register P3. If either P1 or P2 is 0 (false) then the result is 0 even if the other input is NULL. A NULL and true or two NULLs give a NULL output.
## What?
- centralized Rust integration and regression tests
- no new tests added
- no tests removed
- only refactored tests into modules and common utils
## Why?
- @penberg and I have a discussion [here](https://github.com/tursodataba
se/limbo/pull/694#discussion_r1921949665) about centralizing the
integration/ regression tests so that they are not scattered around.
- this is a PR to do that and some refactor of the existing tests to
make the structure easier to navigate + add new tests in the future.
Reviewed-by: Jussi Saurio (@jussisaurio)
Reviewed-by: Preston Thorpe (@PThorpe92)
Reviewed-by: Pere Diaz Bou (@pereman2)
Closes#753
What? adding PRAGMA statements in COMPAT doc.
Why?
- each pragma is quite independent of each other.
- make it clear for contribution.
- maybe lower the bar of contributing.
Closes#760
Change explanation is in the code comment for `Insn::Eq`:
```
/// Jump if either of the operands is null. Used for "jump when false" logic.
/// Eg. "SELECT * FROM users WHERE id = NULL" becomes:
/// <JUMP TO NEXT ROW IF id != NULL>
/// Without the jump_if_null flag it would not jump because the logical comparison "id != NULL" is never true.
/// This flag indicates that if either is null we should still jump.
jump_if_null: bool,
```
Closes#754
Excerpt from SQLite bytecode documentation for e.g. `Lt`:
> If the SQLITE_JUMPIFNULL bit of P5 is set and either reg(P1) or
reg(P3) is NULL then the take the jump. If the SQLITE_JUMPIFNULL bit is
clear then fall through if either operand is NULL.
I didn't want to start putting these flags into a bitmask so I just
added a separate boolean. Probably for sqlite `EXPLAIN` compatibility we
should, IF we want to be exactly compatible (which we aren't anyway atm)
Closes#755
Currently, we are using the same `Parser` instance across multiple
queries (9cc9577c91). But during this
error the parser is not finalized, so parser stack is not reset, thereby
triggering the assertion at https://github.com/tursodatabase/limbo/blob/
15f7928551435458e2991dde3a76ce71e8a32057/vendored/sqlite3-
parser/third_party/lemon/lempar.rs#L663
This PR fixes the panic by calling `sqlite3ParserFinalize()` in the case
of error.
Closes https://github.com/tursodatabase/limbo/issues/742
-----------
`git bisect` FTW
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Reviewed-by: Preston Thorpe (@PThorpe92)
Closes#752
