Trait datafusion_optimizer::optimizer::OptimizerRule

source ·

pub trait OptimizerRule {
    // Required methods
    fn try_optimize(
        &self,
        plan: &LogicalPlan,
        config: &dyn OptimizerConfig
    ) -> Result<Option<LogicalPlan>>;
    fn name(&self) -> &str;

    // Provided method
    fn apply_order(&self) -> Option<ApplyOrder> { ... }
}

Expand description

OptimizerRule transforms one LogicalPlan into another which computes the same results, but in a potentially more efficient way. If there are no suitable transformations for the input plan, the optimizer can simply return it as is.

Required Methods§

source

fn try_optimize( &self, plan: &LogicalPlan, config: &dyn OptimizerConfig ) -> Result<Option<LogicalPlan>>

Try and rewrite plan to an optimized form, returning None if the plan cannot be optimized by this rule.

source

fn name(&self) -> &str

A human readable name for this optimizer rule

Provided Methods§

source

fn apply_order(&self) -> Option<ApplyOrder>

How should the rule be applied by the optimizer? See comments on ApplyOrder for details.

If a rule use default None, it should traverse recursively plan inside itself

Implementors§

source §

impl OptimizerRule for CommonSubexprEliminate

source §

impl OptimizerRule for DecorrelatePredicateSubquery

source §

impl OptimizerRule for EliminateCrossJoin

Attempt to reorder join to eliminate cross joins to inner joins. for queries: ‘select … from a, b where a.x = b.y and b.xx = 100;’ ‘select … from a, b where (a.x = b.y and b.xx = 100) or (a.x = b.y and b.xx = 200);’ ‘select … from a, b, c where (a.x = b.y and b.xx = 100 and a.z = c.z) or (a.x = b.y and b.xx = 200 and a.z=c.z);’ For above queries, the join predicate is available in filters and they are moved to join nodes appropriately This fix helps to improve the performance of TPCH Q19. issue#78

source §