Support planning aggregate indexes #1885
Labels
planner
Related to the query planner
Comments
normen662
pushed a commit
that referenced
this issue
Nov 7, 2022
- this resolves #1885 and adds initial support to planning aggregate indexes (representing the GroupingKeyExpression key expression) to Cascades. - similar to RelationalExpression::subsumedBy, a subsumedBy method is added to Value indicating a subsumption relationship between Value instances, which could be useful as it provides more flexibility in calculating Value-compensation. - FieldValue employs a list of integers indicating the ordinal of each field in its field path, this list is used to check whether a FieldValue subsumes another FieldValue. - Lift various physical implementations of NumericAggregationValue such as sum and avg into their own internal classes so we can annotate them with either StreamableAggregateValue (a value that can be constructed using streaming aggregation) and / or IndexableAggregateValue (a value that can be backed by an aggregate index). This helps with pattern matching, constructing plans, and choosing the right match candidate. Similar work done to CountValue. Added more Matchers for GroupBy constituents. - The generation of the Uber-record is adapted slightly to align it with the addition of field ordinals in FieldValue. It is just a temporary solution though until we have a proper fix, as explained in Uber-record type for FullUnorderedScanExpression is brittle #1884. Had to adapt a number of now-broken plan hash codes in tests because of this. subsumption in GroupByExpression by a match candidate is, for now, exact. This means, for a match to happen, the query must match as-is the match candidate of the respective aggregate index. We will improve on this in the future and make it more robust.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we do not support planning aggregate key expressions in Cascades, it would be beneficial to plan these key expressions to accelerate execution of queries involving these aggregations.
In the first step, we plan queries that match almost 1-1 to the aggregate key expression definition, later on we want to make the planning of aggregate indexes more comprehensive, e.g. support index-anding, support aggregation queries over coarser groups, ... etc. But we would address these improvements in separate tickets.
The purpose of this ticket is to introduce initial support for aggregate indexes.
The text was updated successfully, but these errors were encountered: