Struct EliminateCrossJoin

pub struct EliminateCrossJoin;

Implementations

impl EliminateCrossJoin

pub fn new() -> Self

Trait Implementations

impl Debug for EliminateCrossJoin

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for EliminateCrossJoin

fn default() -> EliminateCrossJoin

Returns the “default value” for a type.

impl OptimizerRule for EliminateCrossJoin

Eliminate cross joins by rewriting them to inner joins when possible.

Example

The initial plan for this query:

select ... from a, b where a.x = b.y and b.xx = 100;

Looks like this:

Filter(a.x = b.y AND b.xx = 100)
 Cross Join
  TableScan a
  TableScan b

After the rule is applied, the plan will look like this:

Filter(b.xx = 100)
  InnerJoin(a.x = b.y)
    TableScan a
    TableScan b

Other Examples

• ‘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);’
• ‘select … from a, b where a.x > b.y’

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

fn supports_rewrite(&self) -> bool

Does this rule support rewriting owned plans (rather than by reference)?

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

Try to rewrite plan to an optimized form, returning Transformed::yes if the plan was rewritten and Transformed::no if it was not.

fn name(&self) -> &str

A human readable name for this optimizer rule

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

👎Deprecated since 40.0.0: please implement supports_rewrite and rewrite instead

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

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

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