normen662
normen662
- fixes a matching problem in `ComputingMatcher` where a join predicate could not be matched because the match was not considered. - change the data access rules in a way...
When the query matches the index perfectly (even the returned values), the fetch that is inserted on top of the index scan will create a complete record instead of just...
For a lot of semantic reasoning we already use a `PartialOrder` to represent orderings. However, for plan annotation and book keeping we use a `List`. That proves to be lossy...
The heuristic planner plans a `rank(score by groups)` filter by use of ranking indexes. This issues addresses the planning of `rank()` in the Cascades planner. The following features should be...
Norse
Currently `Comparison` does not implement `Correlated`. That means that even `ParameterComparison` is not considered to be correlated to anything. There is usage for a `ParameterComparison` which can be a correlation...
The algorithm is exponential, and could be approximated in linear time. *Cough*
This is a follow up to #1142 which refactored the modeling of orderings to model interesting orderings as well as plan properties. One of the things that we didn't model...
``` RecordQuery query = RecordQuery.newBuilder() .setRecordType("MySimpleRecord") .setRequiredResults(Collections.singletonList(field("num_value_3_indexed"))) .build(); ``` The old planner plans this query as an unbounded index scan over some index (`MySimpleRecord$str_value_indexed`) that does not provide `num_value_3_indexed`. That...
We currently use hamcrest matchers to assert on the plan structure in our test cases. That can be problematic for downstream environments that cannot or do not want to use...