mirror of
https://github.com/enso-org/enso.git
synced 2024-12-25 03:43:41 +03:00
1b8b30a68d
- Closes #5303 - Refactors `JoinStrategy` allowing us to 'stack' join strategies on top of each other (to some extent) - currently a `HashJoin` can be followed by another join strategy (currently `SortJoin`) - Adds benchmarks for join - Due to limitations of the sorting approach this will still not be as fast as possible for cases where there is more than 1 `Between` condition in a single query - trying to demonstrate that in benchmarks. - We can replace sorting by d-dimensional [RangeTrees](https://en.wikipedia.org/wiki/Range_tree) to get `O((n + m) log^d n + k)` performance (where `n` and `m` are sizes of joined tables, `d` is the amount of `Between` conditions used in the query and `k` is the result set size). - Follow up ticket for consideration later: #8216 - Closes #8215 - After all, it turned out that `TreeSet` was problematic (because of not enough flexibility with duplicate key handling), so the simplest solution was to immediately implement this sub-task. - Closes #8204 - Unrelated, but I ran into this here: adds type checks to other arguments of `set`. - Before, putting in a Column as `new_name` (i.e. mistakenly messing up the order of arguments), lead to a hard to understand `Method `if_then_else` of type Column could not be found.`, instead now it would file with type error 'expected Text got Column`. |
||
|---|---|---|
| .. | ||
| Map | ||
| Runtime | ||
| Statistics | ||
| Table | ||
| Text | ||
| Time | ||
| Vector | ||
| Collections.enso | ||
| Column_Numeric.enso | ||
| Config.enso | ||
| Equality.enso | ||
| Json_Bench.enso | ||
| Main.enso | ||
| Natural_Order_Sort.enso | ||
| Number_Parse.enso | ||
| Numeric.enso | ||
| Range.enso | ||
| Sum.enso | ||