Files
turso/core
Pekka Enberg ae25a0f088 Merge 'Implement Min/Max aggregators' from Glauber Costa
We have not implemented them before because they require the raw
elements to be kept. It is easy to see why in the following example:
```
current_min = 3;
insert(2) => current_min = 2 // can be done without state
delete(2) => needs to look at the state to determine new min!
```
The aggregator state was a very simple key-value structure. To
accomodate for min/max, we will make it into a more complex table, where
we can encode a more complex structure.
The key insight is that we can use a primary key composed of:
```
1) storage_id
2) zset_id,
3) element
```
The storage_id and zset_id are our previous key, except they are now
exploded to support a larger range of storage_id. With more bits
available in the storage_id, we can encode information about which
column we are storing. For aggregations in multiple columns, we will
need to keep a different list of values for min/max!
The element is just the values of the columns.
Because this is a primary key, the data will be sorted in the btree. We
can then just do a prefix search in the first two components of the key
and easily find the min/max when needed.
This new format is also adequate for joins. Joins will just have a new
storage_id which encodes two "columns" (left side, right side).

Closes #3143
2025-09-16 16:19:59 +03:00
..
2025-09-15 14:48:26 +03:00
2025-09-05 14:56:05 -04:00
2025-09-15 22:30:48 -05:00
2025-06-30 10:01:03 +03:00
2025-09-15 14:48:26 +03:00
2025-08-15 17:08:53 -04:00
2025-01-28 14:55:38 -05:00
2025-09-13 11:00:37 +05:30
2025-06-23 19:52:13 +01:00
2025-08-30 03:10:39 -03:00
2025-01-28 14:55:38 -05:00
2025-06-23 19:52:13 +01:00
2025-06-30 09:54:13 +03:00
2025-09-05 14:56:09 -04:00