Skip to content

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

Merged
xudong963 merged 3 commits intoapache:mainfrom
xudong963:constant_pro
Mar 31, 2026
Merged

Refactor: expose predicate constant inference from physical-expr#21167
xudong963 merged 3 commits intoapache:mainfrom
xudong963:constant_pro

Conversation

@xudong963
Copy link
Copy Markdown
Member

@xudong963 xudong963 commented Mar 26, 2026

Which issue does this PR close?

  • Closes #.

Rationale for this change

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?

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

Are these changes tested?

Yes

Are there any user-facing changes?

@github-actions github-actions bot added physical-expr Changes to the physical-expr crates physical-plan Changes to the physical-plan crate labels Mar 26, 2026
Copy link
Copy Markdown
Member

@asolimando asolimando left a comment

Choose a reason for hiding this comment

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

LGTM, it's nice to expose helpers like this more broadly, it's convenient wherever you have an expression/predicate, which is not necessarily a filter

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 @xudong963 and @asolimando

split_impl(Operator::And, predicate, vec![])
}

/// Collects predicate-derived constants from equality conjunctions.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

To make this more discoverable (aka a greater chance that someone will be able to find it). I recommend making this a method on ConstExpr

So like

let const_exprs = ConstExpr::collect_predicate_constants(,,)

Also, I think an example or two might help (not necessairly code examples, but textural)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Makes sense to me

xudong963 and others added 2 commits March 30, 2026 11:49
…ility

Address alamb's review comment: move `collect_predicate_constants` from a
standalone function to `ConstExpr::collect_predicate_constants()` and add
a textual example to the doc comment.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@xudong963 xudong963 added this pull request to the merge queue Mar 31, 2026
Merged via the queue into apache:main with commit 9c1e7ab Mar 31, 2026
34 checks passed
@xudong963 xudong963 deleted the constant_pro branch March 31, 2026 08:41
xudong963 added a commit to massive-com/arrow-datafusion that referenced this pull request Mar 31, 2026
…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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

physical-expr Changes to the physical-expr crates physical-plan Changes to the physical-plan crate

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants