Internal Refactoring
Since forever, we have had the logicalPlan interface that is used during planning. This served us well on the V3 planner.
In the gen4 work, we introduced the Operator interface that we use when doing the join ordering and route merging.
Once that is done, we transform the operator tree to a logical plan tree to do the grouping/order by/limit planning.
Unfortunately, this means that in some situations we cannot decide early on if we can merge a route with another or not. For example when using derived tables and UNION, if the inner queries are using aggregation, we can't make a good decision during join ordering, and later when we do the aggregation planning, it's too late to merge the routes, because we are by then on logical plans instead.
What I want to do is:
Internal Refactoring
Since forever, we have had the
logicalPlaninterface that is used during planning. This served us well on the V3 planner.In the gen4 work, we introduced the
Operatorinterface that we use when doing the join ordering and route merging.Once that is done, we transform the operator tree to a logical plan tree to do the grouping/order by/limit planning.
Unfortunately, this means that in some situations we cannot decide early on if we can merge a route with another or not. For example when using derived tables and UNION, if the inner queries are using aggregation, we can't make a good decision during join ordering, and later when we do the aggregation planning, it's too late to merge the routes, because we are by then on logical plans instead.
What I want to do is:
sum(distinct col)))Hopefully the refactoring should make the code easier to work with and understand as well.