Cost-Based Optimization of Integration Flows - Datenbanken ...

6.2 Plan Optimality Trees
• Optimality: The optimality of a plan is represented by the PlanOptTree. If and only
if any optimality condition is violated, we will find a plan with lower cost during
re-optimization. Thus, there is no need to trigger re-optimization until we detect
any violation (break-even point between optimality of different plans).
• Transitivity: If a statistic is included in multiple optimality conditions, we can leverage
the transitivity of the comparison operators θ. Thus, the total number of required
optimality conditions can be reduced.
• Directed Optimization: If an optimality condition is violated, we are able to easily
determine the involved operators and the related optimization technique that produced
this condition. Then, we only need to directly re-optimize those operators.
These properties hold for a complete PlanOptTree, while a set of partial PlanOptTrees
(here, partial is defined as a subset of optimality conditions) might include redundancy,
which stands in conflict with minimal monitoring and transitivity. We will revisit this
issue and explain its relevance for further optimization later on.
6.2.2 Creating PlanOptTrees
During the initial deployment of an integration flow, the full cost-based optimization is executed
once. There, the complete plan search space is evaluated and an initial PlanOptTree
is created. From this point, the PlanOptTree is used for incremental and directed reoptimization
only. In this subsection, we explain how to create this initial PlanOptTree.
Our standard (transformation-based) optimization algorithm A-PMO recursively iterates
over the hierarchy of sequences of atomic and complex operators (internal representation
of a plan) and changes the current plan by applying relevant optimization techniques
according to the specific types of operators. In contrast, for on-demand re-optimization, we
changed the optimizer interface. Now, the optimizer does not only change the current plan
but additionally, each applied optimization technique returns also a partial PlanOptTree
that represents the optimality conditions for the subplan that was considered by this technique.
This extension of optimization techniques is straightforward because the existing
cost functions and optimality conditions can be reused. For example, the technique WD4:
Early Selection Application creates a partial PlanOptTree when considering two operators.
This technique constructs the partial PlanOptTree using ONodes, SNodes, a specialized
CSNode Selectivity, and an OCNode.
The use of the fine-grained partial PlanOptTrees at the optimizer interface is advantageous
because during directed re-optimization, only subplans are considered and hence,
only partial PlanOptTrees can be returned. Thus, the solution to the challenge of creating
the initial PlanOptTree is to merge all partial PlanOptTrees to a minimal representation.
Example 6.4 (Merging Partial PlanOptTrees). Recall plan P 5 and assume the two partial
PlanOptTrees (created for the operators o 2 and o 3 ) shown in Figures 6.6(a) and 6.6(b).
When merging those two partial PlanOptTrees, we see that operator o 3 and its selectivity
(as a CSNode) are used by both partial PlanOptTrees. Hence, we add only o 4 and all
of its child nodes from POT 2 to POT 1 . When doing so, the dangling reference from the
new optimality condition to sel(o 3 ) of POT 2 is modified to refer to the existing selectivity
measure sel(o 3 ) of POT 1 . Finally, we created the PlanOptTree shown in Figure 6.6(c).
Algorithm 6.1 describes the creation of a PlanOptTree in detail. We iterate over all
operators of a given subplan (lines 2-22). If an operator contains a subplan, we recursively
173