Skip to content

Refactor: expose predicate constant inference from physical-expr#44

Merged
xudong963 merged 1 commit into
branch-52from
xudong963/branch52-9c1e7a
Mar 31, 2026
Merged

Refactor: expose predicate constant inference from physical-expr#44
xudong963 merged 1 commit into
branch-52from
xudong963/branch52-9c1e7a

Conversation

@xudong963

Copy link
Copy Markdown
Collaborator

Summary

  • cherry-pick upstream commit 9c1e7abd2fedfc52525ce1662dd9f650171d0c5c onto branch-52
  • expose predicate constant inference from datafusion-physical-expr and update filter stats code to use it

Testing

  • cargo test -p datafusion-physical-expr utils::tests --lib
  • cargo test -p datafusion-physical-plan filter::tests --lib

Cherry-picked from upstream commit 9c1e7abd2fedfc52525ce1662dd9f650171d0c5c.

…che#21167)

## 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 apache#123` indicates that this PR will close issue apache#123.
-->

- Closes #.

## 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.
-->

The predicate constant inference logic is helpful, we also use it in in
our product, but we just copied that becuase it's now in the filter's
method.

## What changes are included in this PR?

<!--
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.
-->

The PR extracts the related logic into a helper method in physical expr.

## Are these changes tested?

<!--
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)?
-->

Yes

## Are there any user-facing changes?

<!--
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.
-->

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
(cherry picked from commit 9c1e7ab)
@xudong963 xudong963 merged commit 5e03e56 into branch-52 Mar 31, 2026
58 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant