Skip to content

fix: skips projection pruning for whole subtree#20545

Merged
Dandandan merged 3 commits intoapache:mainfrom
Acfboy:fix-skip-optimize-projections
Apr 8, 2026
Merged

fix: skips projection pruning for whole subtree#20545
Dandandan merged 3 commits intoapache:mainfrom
Acfboy:fix-skip-optimize-projections

Conversation

@Acfboy
Copy link
Copy Markdown
Contributor

@Acfboy Acfboy commented Feb 25, 2026

Which issue does this PR close?

Rationale for this change

In UserDefinedLogicalNodeCore, the default implementation of necessary_children_exprs returns None, which signals to the optimizer that it cannot determine which columns are required from the child.

The optimizer takes a conservative approach and skips projection pruning for that node, leading to complex and redundant plans in the subtree. However, it would make more sense to assume all columns are required and let the optimizer proceed, rather than giving up on the entire subtree entirely.

What changes are included in this PR?

LogicalPlan::Extension(extension) => {
    if let Some(necessary_children_indices) =
        extension.node.necessary_children_exprs(indices.indices())
    {
        ...
    } else {
        // Requirements from parent cannot be routed down to user defined logical plan safely
        // Assume it requires all input exprs here
        plan.inputs()
            .into_iter()
            .map(RequiredIndices::new_for_all_exprs)
            .collect()
    }
}

instead of

LogicalPlan::Extension(extension) => {
let Some(necessary_children_indices) =
extension.node.necessary_children_exprs(indices.indices())
else {
// Requirements from parent cannot be routed down to user defined logical plan safely
return Ok(Transformed::no(plan));
};

Are these changes tested?

Yes.

In addition to unit tests, I've also added a complete end-to-end integration test that reproduces the full scenario in the issue. This might seem redundant, bloated, or even unnecessary. Please let me know if I should remove these tests.

An existing test is modified, but I think the newer behavior is expected.

Are there any user-facing changes?

Yes. But I think the new implementation is the expected behavior.

@github-actions github-actions bot added the optimizer Optimizer rules label Feb 25, 2026
@Acfboy Acfboy marked this pull request as draft February 25, 2026 13:35
@github-actions github-actions bot added the core Core DataFusion crate label Feb 25, 2026
@Acfboy Acfboy marked this pull request as ready for review February 25, 2026 15:04
Copy link
Copy Markdown
Contributor

@neilconway neilconway left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks -- lgtm!

@alamb alamb added the performance Make DataFusion faster label Mar 10, 2026
@Acfboy
Copy link
Copy Markdown
Contributor Author

Acfboy commented Apr 7, 2026

Just updated the branch to resolve the out-of-date status. Ready for a final look when you have a chance @alamb . Thanks!

Copy link
Copy Markdown
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @neilconway and @Acfboy

@alamb
Copy link
Copy Markdown
Contributor

alamb commented Apr 7, 2026

FYI @niebayes

@Dandandan Dandandan added this pull request to the merge queue Apr 8, 2026
Merged via the queue into apache:main with commit f4e24a5 Apr 8, 2026
35 checks passed
Dandandan pushed a commit to Dandandan/arrow-datafusion that referenced this pull request Apr 8, 2026
## Which issue does this PR close?

<!--
We generally require a GitHub issue to be filed for all bug fixes and
enhancements and this helps us generate change logs for our releases.
You can link an issue to this PR using the GitHub syntax. For example
`Closes #123` indicates that this PR will close issue #123.
-->

- Closes apache#18816 .

## Rationale for this change

<!--
Why are you proposing this change? If this is already explained clearly
in the issue then this section is not needed.
Explaining clearly why changes are proposed helps reviewers understand
your changes and offer better suggestions for fixes.
-->
In `UserDefinedLogicalNodeCore`, the default implementation of
`necessary_children_exprs ` returns `None`, which signals to the
optimizer that it cannot determine which columns are required from the
child.

The optimizer takes a conservative approach and skips projection pruning
for that node, leading to complex and redundant plans in the subtree.
However, it would make more sense to assume all columns are required and
let the optimizer proceed, rather than giving up on the entire subtree
entirely.

## What changes are included in this PR?

```rust
LogicalPlan::Extension(extension) => {
    if let Some(necessary_children_indices) =
        extension.node.necessary_children_exprs(indices.indices())
    {
        ...
    } else {
        // Requirements from parent cannot be routed down to user defined logical plan safely
        // Assume it requires all input exprs here
        plan.inputs()
            .into_iter()
            .map(RequiredIndices::new_for_all_exprs)
            .collect()
    }
}
```

instead of 


https://github.com/apache/datafusion/blob/b6d46a63824f003117297848d8d83b659ac2e759/datafusion/optimizer/src/optimize_projections/mod.rs#L331-L337
<!--
There is no need to duplicate the description in the issue here but it
is sometimes worth providing a summary of the individual changes in this
PR.
-->

## Are these changes tested?

Yes.

In addition to unit tests, I've also added a complete end-to-end
integration test that reproduces the full scenario in the issue. This
might seem redundant, bloated, or even unnecessary. Please let me know
if I should remove these tests.

An existing test is modified, but I think the newer behavior is
expected.
<!--
We typically require tests for all PRs in order to:
1. Prevent the code from being accidentally broken by subsequent changes
2. Serve as another way to document the expected behavior of the code

If tests are not included in your PR, please explain why (for example,
are they covered by existing tests)?
-->

## Are there any user-facing changes?

Yes. But I think the new implementation is the expected behavior.
<!--
If there are user-facing changes then we may require documentation to be
updated before approving the PR.
-->

<!--
If there are any breaking changes to public APIs, please add the `api
change` label.
-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core Core DataFusion crate optimizer Optimizer rules performance Make DataFusion faster

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: unnecessary columns projected and redundant filters pushed down

5 participants