Jussi Saurio
cbe3500b7e
Merge 'Code clean-ups' from Diego Reis
...
While developing I found that some things could be improved :)
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes #1325
2025-04-13 17:02:12 +03:00
pedrocarlo
1297cb107c
bit-not and boolean-not
...
Co-authored-by: Diego Reis <79876389+diegoreis42@users.noreply.github.com>
2025-04-13 02:45:12 -03:00
Diego Reis
51eb2af06a
core(refactor): Add CreateBTreeFlags
...
Passing 1s and 0s with comments is not rustacean, and since we already follow the pattern of struct flags in other sections of the codebase it's better use it here too.
2025-04-13 01:46:30 -03:00
Levy A.
5c0b112125
fix: return null when parameter is unbound
2025-04-12 17:43:04 -03:00
meteorgan
8200b328d8
support modifiers for julianday()
2025-04-12 19:29:20 +08:00
Pekka Enberg
d67e1b604b
Merge 'Added 'likelihood' scalar function' from Sachin Kumar Singh
...
The `likelihood(X,Y)` function returns argument X unchanged. The value Y
in likelihood(X,Y) must be a floating point constant between 0.0 and
1.0, inclusive.
```
sqlite> explain SELECT likelihood(42, 0.0);
addr opcode p1 p2 p3 p4 p5 comment
---- ------------- ---- ---- ---- ------------- -- -------------
0 Init 0 6 0 0 Start at 6
1 Once 0 3 0 0
2 Integer 42 2 0 0 r[2]=42
3 Copy 2 1 0 0 r[1]=r[2]
4 ResultRow 1 1 0 0 output=r[1]
5 Halt 0 0 0 0
6 Goto 0 1 0 0
```
```
limbo> explain SELECT likelihood(42, 0.0);
addr opcode p1 p2 p3 p4 p5 comment
---- ----------------- ---- ---- ---- ------------- -- -------
0 Init 0 4 0 0 Start at 4
1 Copy 2 1 0 0 r[1]=r[2]
2 ResultRow 1 1 0 0 output=r[1]
3 Halt 0 0 0 0
4 Integer 42 2 0 0 r[2]=42
5 Goto 0 1 0 0
```
Closes #1303
2025-04-11 09:34:36 +03:00
Sachin Singh
01fa02364d
correctly handle edge cases
2025-04-11 08:34:29 +05:30
Sachin Singh
482e93bfd0
feat: add likelihood scalar function
2025-04-11 05:54:23 +05:30
Sachin Singh
b7acfa490c
feat: add timediff data and time function
2025-04-11 04:30:57 +05:30
Pere Diaz Bou
8e93471d00
fix cell index selection while balancing
...
Cell index doesn't move in `move_to` unless we don't need to check next
cell. On the other hand, with rightmost pointer, we advance cell index
by 1 even though where we are moving to was to that page
2025-04-10 16:01:24 +02:00
Pekka Enberg
31f0d174d7
core/vdbe: Move exec_*() funtions to execute.rs
2025-04-10 09:42:03 +03:00
Pekka Enberg
5906d7971a
core/vdbe: Clean up imports
2025-04-10 09:25:15 +03:00
PThorpe92
13ae19c78c
Remove unnecessary clones from mc cursors
2025-04-09 11:15:04 -04:00
PThorpe92
62d1447cd6
Adapt query plan to handle vatbs for updates
2025-04-09 11:15:02 -04:00
Pekka Enberg
ddc5e49451
Merge 'Index insert fixes' from Pere Diaz Bou
...
Closes #1279
2025-04-09 17:21:53 +03:00
Pekka Enberg
a4d9f70ef8
Merge 'Strict table support' from Ihor Andrianov
...
Closes #884
Support for
```CREATE TABLE test(id INTEGER) STRICT;```
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes #1268
2025-04-09 16:45:56 +03:00
Pere Diaz Bou
12899034c9
make insert idx re-entrant
2025-04-09 15:04:45 +02:00
Jussi Saurio
3e42a62cd0
Add SeekLE/SeekLT operations to VDBE
2025-04-09 10:14:29 +03:00
PThorpe92
6b5ec1f07b
Remove mut borrow from sym table in parse schema fn
2025-04-08 20:10:49 -04:00
PThorpe92
c15035caf8
Add module and vtab to schema after table is reopened with proper ext
2025-04-08 20:10:48 -04:00
PThorpe92
4b9b6c969b
Parse schema rows after extensions are loaded
2025-04-08 20:10:47 -04:00
Ihor Andrianov
7c15465118
add TypeCheck insn to update
2025-04-07 20:02:14 +03:00
Ihor Andrianov
4a08b98bab
implemented strict table
2025-04-07 20:01:39 +03:00
Duncan Lutz
aa7c64cb19
feat: added likely scalar function
2025-04-06 23:14:30 -06:00
Pekka Enberg
2d3fd01f91
Merge 'Support Create Index' from Preston Thorpe
...
Closes #1193
```console
│limbo> explain create index idxp on products(price);
│addr opcode p1 p2 p3 p4 p5 comment
│---- ----------------- ---- ---- ---- ------------- -- -------
│0 Init 0 39 0 0 Start at 39
│1 CreateBtree 0 1 2 0 r[1]=root iDb=0 flags=2
│2 OpenWriteAsync 0 1 0 0
│3 OpenWriteAwait 0 0 0 0
│4 NewRowId 0 2 0 0
│5 String8 0 3 0 index 0 r[3]='index'
│6 String8 0 4 0 idxp 0 r[4]='idxp'
│7 String8 0 5 0 products 0 r[5]='products'
│8 Copy 1 6 1 0 r[6]=r[1]
│9 String8 0 7 0 CREATE INDEX idxp ON products (price) 0 r[7]='CREATE INDEX idxp ON products (price)'
│10 MakeRecord 3 5 8 0 r[8]=mkrec(r[3..7])
│11 InsertAsync 0 8 2 0
│12 InsertAwait 0 0 0 0
│13 SorterOpen 3 1 0 k(1,B) 0 cursor=3
│14 OpenPseudo 4 9 2 0 2 columns in r[9]
│15 OpenReadAsync 2 273 0 0 table=products, root=273
│16 OpenReadAwait 0 0 0 0
│17 RewindAsync 2 0 0 0
│18 RewindAwait 2 25 0 0 Rewind table products
│19 Column 2 2 10 0 r[10]=products.price
│20 RowId 2 11 0 0 r[11]=products.rowid
│21 MakeRecord 10 2 12 0 r[12]=mkrec(r[10..11])
│22 SorterInsert 3 12 0 0 0 key=r[12]
│23 NextAsync 2 0 0 0
│24 NextAwait 2 19 0 0
│25 OpenWriteAsync 1 1 0 0
│26 OpenWriteAwait 0 0 0 0
│27 SorterSort 3 33 0 0
│28 SorterData 3 13 4 0 r[13]=data
│29 SeekEnd 1 0 0 0
│30 IdxInsertAsync 1 13 0 0 key=r[13]
│31 IdxInsertAwait 1 0 0 0
│32 SorterNext 3 28 0 0
│33 Close 3 0 0 0
│34 Close 2 0 0 0
│35 Close 1 0 0 0
│36 ParseSchema 0 0 0 name = 'idxp' AND type = 'index' 0 name = 'idxp' AND type = 'index'
│37 Close 0 0 0 0
│38 Halt 0 0 0 0
│39 Transaction 0 1 0 0 write=true
│40 Goto 0 1 0 0
```
This will create the initial index btree and insert whatever relevant
records that need to be inserted, it doesn't handle the case of
inserting new index keys when normal records are created afterwards.
That will prob be added in next PR to keep this one concise.
Limbo will properly use the index in a subsequent query:
Creating a unique index on a column that has 2 existing identical rows:
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes #1199
2025-04-06 19:32:36 +03:00
PThorpe92
67eda10453
Allow reading altered tables by defaulting to null in Column insn
2025-04-05 16:19:56 -04:00
PThorpe92
068ab4ab27
Refactor btree to reuse existing insert and seek with idx keys
2025-04-05 11:19:09 -04:00
PThorpe92
e020ba3dfe
Add enum for interpreting a value as a register or literal for insns
2025-04-05 11:19:07 -04:00
PThorpe92
b0016a0ee2
Support create index with SeekEnd and IdxCreate opcode functionality
2025-04-05 11:15:36 -04:00
PThorpe92
ae2be30204
Move init label to proper place in create vtab translation
2025-04-03 20:22:14 -04:00
Pekka Enberg
24063bd9c0
core/vdbe: Add newline between op functions
2025-04-02 18:57:07 +03:00
Pekka Enberg
3420955db7
core/vdbe: Rename execute_insn_* to op_*
...
The "execute::execute_insn" prefix is noisy, let's rename the
instruction operation functions to something shorter and sweeter.
2025-04-02 18:02:02 +03:00
Pere Diaz Bou
66f70d571d
fmt
2025-04-02 13:14:26 +00:00
Pere Diaz Bou
f5221589f0
remove wrong usage of feature = json
2025-04-02 15:00:51 +02:00
Pere Diaz Bou
7e4b57f2e2
VDBE with direct function dispatch
...
This PR is unapologetically stolen from @vmg's implementation in Vitess
implemented here https://github.com/vitessio/vitess/pull/12369 . If you
want a more in depth explanation of how this works you can read the
[blog post he carefully
wrote](https://planetscale.com/blog/faster-interpreters-in-go-catching-up-with-cpp ).
In limbo we have a huge problem with [register
spilling](https://en.wikipedia.org/wiki/Register_allocation ), this can
be easily observed with the prolog of `Program::step` before:
```llvm
start:
%e.i.i304.i = alloca [0 x i8], align 8
%formatter.i305.i = alloca [64 x i8], align 8
%buf.i306.i = alloca [24 x i8], align 8
%formatter.i259.i = alloca [64 x i8], align 8
..................... these are repeated for hundreds of lines
.....................
%formatter.i52.i = alloca [64 x i8], align 8
%buf.i53.i = alloca [24 x i8], align 8
%formatter.i.i = alloca [64 x i8], align 8
%buf.i.i = alloca [24 x i8], align 8
%_87.i = alloca [48 x i8], align 8
%_82.i = alloca [24 x i8], align 8
%_73.i = alloca [24 x i8], align 8
%_66.i8446 = alloca [24 x i8], align 8
%_57.i = alloca [24 x i8], align 8
%_48.i = alloca [24 x i8], align 8
```
After these changes we completely remove the need of register spilling
(yes that is the complete prolog):
```llvm
start:
%self1 = alloca [80 x i8], align 8
%pager = alloca [8 x i8], align 8
%mv_store = alloca [8 x i8], align 8
store ptr %0, ptr %mv_store, align 8
store ptr %1, ptr %pager, align 8
%2 = getelementptr inbounds i8, ptr %state, i64 580
%3 = getelementptr inbounds i8, ptr %state, i64 576
%4 = getelementptr inbounds i8, ptr %self, i64 16
%5 = getelementptr inbounds i8, ptr %self, i64 8
%6 = getelementptr inbounds i8, ptr %self1, i64 8
br label %bb1, !dbg !286780
```
When it comes to branch prediction, we don't really fix a lot because
thankfully rust already compiles `match` expressions
to a jump table:
```llvm
%insn = getelementptr inbounds [0 x %"vdbe::insn::Insn"], ptr %self657,
i64 0, i64 %index, !dbg !249527
%332 = load i8, ptr %insn, align 8, !dbg !249528 , !range !38291 ,
!noundef !14
switch i8 %332, label %default.unreachable26674 [
i8 0, label %bb111
i8 1, label %bb101
i8 2, label %bb100
i8 3, label %bb110
...
i8 104, label %bb5
i8 105, label %bb16
i8 106, label %bb14
], !dbg !249530
```
Some results
----
```
function dispatch:
Execute `SELECT 1`/limbo_execute_select_1
time: [29.498 ns 29.548 ns 29.601 ns]
change: [-3.6125% -3.3592% -3.0804%] (p = 0.00 <
0.05)
main:
Execute `SELECT 1`/limbo_execute_select_1
time: [33.789 ns 33.832 ns 33.878 ns]
```
2025-04-02 14:55:37 +02:00
