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]

It looks like the reason for using SingleIterator (with null argument) instead of EmptyIterator is related to returning empty list, compared to returning null in EmptyIterator when calling computeNext, is that so, why not just use EmptyIterator instead and let the customer deal with the null?

[normen662]

EmptyIterator does not return any item. It is endOfData() immediately. This one does return the empty list. Some combinatorics algorithms want nothing on empty while some others like the topological sort want an empty result on empty input. We thus need both I think.

[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.