Dummy Optimizers#
Provides empty (dummy) strategies for the individual optimization stages.
- class postbound.opt.noopt.EmptyJoinOrderOptimizer(*args, **kwargs)#
Dummy implementation of the join order optimizer that does not actually optimize anything.
- optimize_join_order(query: SqlQuery) JoinTree | None#
Performs the actual join ordering process.
The join tree can be further annotated with an initial operator assignment, if that is an inherent part of the specific optimization strategy. However, this is generally discouraged and the multi-stage pipeline will discard such operators to prepare for the subsequent physical operator selection.
Other than the join order and operator assignment, the algorithm should add as much information to the join tree as possible, e.g. including join conditions and cardinality estimates that were calculated for the selected joins. This enables other parts of the optimization process to re-use that information.
- Parameters:
query (SqlQuery) – The query to optimize
- Returns:
The join order. If for some reason there is no valid join order for the given query (e.g. queries with just a single selected table), None can be returned. Otherwise, the selected join order has to be described using a JoinTree.
- Return type:
Optional[LogicalJoinTree]
- describe() dict#
Provides a JSON-serializable representation of the specific strategy, as well as important parameters.
- Returns:
The description
- Return type:
jsondict
See also
OptimizationPipeline.describe
- class postbound.opt.noopt.EmptyPhysicalOperatorSelection(*args, **kwargs)#
Dummy implementation of operator optimization that does not actually optimize anything.
- select_physical_operators(query: SqlQuery, join_order: JoinTree | None) PhysicalOperatorAssignment#
Performs the operator assignment.
- Parameters:
- Returns:
The operator assignment. If for some reason no operators can be assigned, an empty assignment can be returned
- Return type:
Notes
The operator selection should handle a None join order gracefully. This can happen if the query does not require any joins (e.g. processing of a single table.
Depending on the specific optimization settings, it is also possible to raise an error if such a situation occurs and there is no reasonable way to deal with it.
- describe() dict#
Provides a JSON-serializable representation of the specific strategy, as well as important parameters.
- Returns:
The description
- Return type:
jsondict
See also
OptimizationPipeline.describe
- class postbound.opt.noopt.EmptyParameterization(*args, **kwargs)#
Dummy implementation of the plan parameterization that does not actually generate any parameters.
- generate_plan_parameters(query: SqlQuery, join_order: JoinTree | None, operator_assignment: PhysicalOperatorAssignment | None) PlanParameterization | None#
Executes the actual parameterization.
- Parameters:
query (SqlQuery) – The query to optimize
join_order (Optional[JoinTree]) – The selected join order for the query.
operator_assignment (Optional[PhysicalOperatorAssignment]) – The selected operators for the query
- Returns:
The parameterization. If for some reason no parameters can be determined, an empty parameterization can be returned
- Return type:
Notes
Since this is the final stage of the optimization process, a number of special cases have to be handled:
the previous phases might not have determined any join order or operator assignment
there might not have been a physical operator selection, but only a join ordering (which potentially included an initial selection of physical operators)
there might not have been a join order optimization, but only a selection of physical operators
both join order and physical operators might have been optimized (in which case only the actual operator assignment matters, not any assignment contained in the join order)
- describe() dict#
Provides a JSON-serializable representation of the specific strategy, as well as important parameters.
- Returns:
The description
- Return type:
jsondict
See also
OptimizationPipeline.describe