Expand description
Filter Pushdown Optimization Process
The filter pushdown mechanism involves four key steps:
- Optimizer Asks Parent for a Filter Pushdown Plan: The optimizer calls
ExecutionPlan::gather_filters_for_pushdown
on the parent node, passing in parent predicates and phase. The parent node creates aFilterDescription
by inspecting its logic and children’s schemas, determining which filters can be pushed to each child. - Optimizer Executes Pushdown: The optimizer recursively pushes down filters for each child,
passing the appropriate filters (
Vec<Arc<dyn PhysicalExpr>>
) for that child. - Optimizer Gathers Results: The optimizer collects
FilterPushdownPropagation
results from children, containing information about which filters were successfully pushed down vs. unsupported. - Parent Responds: The optimizer calls
ExecutionPlan::handle_child_pushdown_result
on the parent, passing aChildPushdownResult
containing the aggregated pushdown outcomes. The parent decides how to handle filters that couldn’t be pushed down (e.g., keep them as FilterExec nodes).
See also datafusion/physical-optimizer/src/filter_pushdown.rs.
Structs§
- Child
Filter Description - Describes filter pushdown for a single child node.
- Child
Filter Pushdown Result - The result of pushing down a single parent filter into all children.
- Child
Pushdown Result - The result of pushing down filters into a child node.
- Filter
Description - Describes how filters should be pushed down to children.
- Filter
Pushdown Propagation - The result of pushing down filters into a node.
- Pushed
Down Predicate - The result of a plan for pushing down a filter into a child node. This contains references to filters so that nodes can mutate a filter before pushing it down to a child node (e.g. to adjust a projection) or can directly take ownership of filters that their children could not handle.
Enums§
- Filter
Pushdown Phase - Pushed
Down - Discriminant for the result of pushing down a filter into a child node.