Composite aggregates

[normen662]

This PR adds the ability to plan arbitrary aggregation queries using aggregation indexes as well as intersections of aggregation indexes. It also corrects/adds the infrastructure to deal with complicated order-by requirements.

• refactor data access rules into a data access rule for value indexes and one for aggregation indexes
• have both of these data access rule implementations share the maximum code (only intersection planning is different)
• intersection planning for aggregation indexes
  • because of the same reasoning as regular index intersections AND in order to answer the query as these indexes carry data that is not part of the underlying table (the aggregation)
  • rollups of finer-granularity index scans if such a roll-up can be useful in answering the query
• order by requirements are treated in the same framework as all other kinds of expressions (using M3 maps, translations, etc.)

[hatyo]

I believe we can immediately return IntersectionResult.noViableIntersection() if the resulting intersection compensation is impossible, correct?

[normen662]

No. It may be that we are currently impossible but that there is a common ordering (in fact there must be one for the follow up to work). If there is no common ordering the result will be discarded. If there is a common ordering but it is currently impossible to (think 2 out of 3 aggregate functions are satisfied), we want that intersection access to survive because otherwise we would never get to the intersection that creates the one where we get 3 out of 3.

[hatyo]

It would be nice to add some comments explaining the handling of matched group by aggregations and groups here.

[normen662]

I extracted the common code between SelectExpression, LogicalTypeFileExpression, and GroupByExpression. The new code also has some documentation.

[hatyo]

I don't think it is possible to retrieve an IntersectionResult which non-empty list of RelationalExpressions and null-common ordering, if we examine the code flow above.

Having said that, we could probably cleanup the code, such that we can remove the hasCommonFlag maybe?

[normen662]

No, You can have a common ordering but no expressions due to the compensation being impossible. You still want to signal the caller to keep this intersection (even though you didn't produce a single expression) in the sieve so you can potentially find a bigger intersection that is not impossible.

[hatyo]

Great work, let's bring it in.