File tree Expand file tree Collapse file tree 2 files changed +8
-3
lines changed Expand file tree Collapse file tree 2 files changed +8
-3
lines changed Original file line number Diff line number Diff line change 21
21
//! 1. **Optimizer Asks Parent for a Filter Pushdown Plan**: The optimizer calls [`ExecutionPlan::gather_filters_for_pushdown`]
22
22
//! on the parent node, passing in parent predicates and phase. The parent node creates a [`FilterDescription`]
23
23
//! by inspecting its logic and children's schemas, determining which filters can be pushed to each child.
24
- //! 2. **Optimizer Executes Pushdown**: The optimizer recursively calls [ `push_down_filters`] on each child,
24
+ //! 2. **Optimizer Executes Pushdown**: The optimizer recursively calls `push_down_filters` in this module on each child,
25
25
//! passing the appropriate filters (`Vec<Arc<dyn PhysicalExpr>>`) for that child.
26
26
//! 3. **Optimizer Gathers Results**: The optimizer collects [`FilterPushdownPropagation`] results from children,
27
27
//! containing information about which filters were successfully pushed down vs. unsupported.
28
28
//! 4. **Parent Responds**: The optimizer calls [`ExecutionPlan::handle_child_pushdown_result`] on the parent,
29
29
//! passing a [`ChildPushdownResult`] containing the aggregated pushdown outcomes. The parent decides
30
30
//! how to handle filters that couldn't be pushed down (e.g., keep them as FilterExec nodes).
31
+ //!
32
+ //! [`FilterDescription`]: datafusion_physical_plan::filter_pushdown::FilterDescription
31
33
32
34
use std:: sync:: Arc ;
33
35
Original file line number Diff line number Diff line change 18
18
//! Filter Pushdown Optimization Process
19
19
//!
20
20
//! The filter pushdown mechanism involves four key steps:
21
- //! 1. **Optimizer Asks Parent for a Filter Pushdown Plan**: The optimizer calls `ExecutionPlan::gather_filters_for_pushdown`
21
+ //! 1. **Optimizer Asks Parent for a Filter Pushdown Plan**: The optimizer calls [ `ExecutionPlan::gather_filters_for_pushdown`]
22
22
//! on the parent node, passing in parent predicates and phase. The parent node creates a [`FilterDescription`]
23
23
//! by inspecting its logic and children's schemas, determining which filters can be pushed to each child.
24
24
//! 2. **Optimizer Executes Pushdown**: The optimizer recursively pushes down filters for each child,
25
25
//! passing the appropriate filters (`Vec<Arc<dyn PhysicalExpr>>`) for that child.
26
26
//! 3. **Optimizer Gathers Results**: The optimizer collects [`FilterPushdownPropagation`] results from children,
27
27
//! containing information about which filters were successfully pushed down vs. unsupported.
28
- //! 4. **Parent Responds**: The optimizer calls `ExecutionPlan::handle_child_pushdown_result` on the parent,
28
+ //! 4. **Parent Responds**: The optimizer calls [ `ExecutionPlan::handle_child_pushdown_result`] on the parent,
29
29
//! passing a [`ChildPushdownResult`] containing the aggregated pushdown outcomes. The parent decides
30
30
//! how to handle filters that couldn't be pushed down (e.g., keep them as FilterExec nodes).
31
+ //!
32
+ //! [`ExecutionPlan::gather_filters_for_pushdown`]: crate::ExecutionPlan::gather_filters_for_pushdown
33
+ //! [`ExecutionPlan::handle_child_pushdown_result`]: crate::ExecutionPlan::handle_child_pushdown_result
31
34
//!
32
35
//! See also datafusion/physical-optimizer/src/filter_pushdown.rs.
33
36
You can’t perform that action at this time.
0 commit comments