Add field to DynamicPhysicalExpr to indicate when the filter is complete or updated #18799
+257
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
physical-expr
LiaCastaneda
force-pushed
the
lia/add-function-is_complete
branch
from
5528b6e to
dffd77b
Compare
LiaCastaneda
changed the title
Contributor
|
Will take a look at this one soon |
Contributor
|
This makes sense and is a relatively simple change, but could you share an example use case? Would the scan node care if the filter is complete/in progress? |
gabotechs
reviewed
Nov 19, 2025
LiaCastaneda
force-pushed
the
lia/add-function-is_complete
branch
from
28c5406 to
278c3bb
Compare
adriangb
approved these changes
Nov 19, 2025
Contributor
adriangb
left a comment
adriangb
left a comment
There was a problem hiding this comment.
This looks great! I do think it would be good to have some tests:
- Unit tests for
DynamicFilterPhysicalExpr - Unit tests for
TopK/SortExecandHashJoinExecto ensure they mark the filter as completed.
LiaCastaneda
commented
Nov 19, 2025
LiaCastaneda
force-pushed
the
lia/add-function-is_complete
branch
2 times, most recently
from
3c40331 to
c6a91b6
Compare
LiaCastaneda
force-pushed
the
lia/add-function-is_complete
branch
from
c10ef72 to
3115cfb
Compare
LiaCastaneda
changed the title
adriangb
approved these changes
Nov 19, 2025
Contributor
|
Will give it until tomorrow in case anyone else want to chime in, and otherwise merge it then. |
Contributor
Author
|
Thanks for the reviews @adriangb and @gabotechs 🙇 |
2010YOUY01
approved these changes
Nov 20, 2025
| let array: ArrayRef = Arc::new(Int32Array::from(vec![Some(3), Some(1), Some(2)])); | ||
| let batch = RecordBatch::try_new(Arc::clone(&schema), vec![array])?; | ||
| topk.insert_batch(batch)?; | ||
|
|
Contributor
There was a problem hiding this comment.
Should we also do an assertion for 'in progress' here.
Contributor
Author
There was a problem hiding this comment.
Yeah, the issue is that its hard to set up in the tests a wait_update before the update happens without doing something like tokio::spawn (which I think is not allowed to use in tests) or setting a timeout which would introduce some indeterminism to the test
Contributor
Author
|
I think this PR might slightly conflict logically with #18451 -- I have to update the branch before merging |
Contributor
|
Thanks @LiaCastaneda for the PR and @adriangb and @2010YOUY01 for the reviews! |
LiaCastaneda
added a commit
to DataDog/datafusion
that referenced
this pull request
Nov 20, 2025
…ete or updated (apache#18799) <!-- 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 #. Dynamic filter pushdown in DataFusion currently lacks an API to determine when filters are "complete" (all contributing partitions have reported), this creates an ambiguity issue where it's impossible to differentiate between: 1. **Complete filter with no data**: Build side produced 0 rows, filter remains as placeholder `lit(true)`, no more updates coming 2. **Incomplete filter**: Filter is still being computed, updates are pending I think this could be especially useful when we want to make the filter updates progressively in the future. - Calls `mark_complete()` after barrier completes, regardless of whether bounds exist. - Exposes` is_complete() f`unction on the `DynamicFilterPhysicalExpr`. I didn't add any tests because the change is minimal , and comprehensive testing would require making the `DynamicFilterPhysicalExpr` public or running through the full optimizer pipeline. Exposing is_complete() function. (cherry picked from commit 7fa2a69)
This was referenced Nov 20, 2025
LiaCastaneda
added a commit
to DataDog/datafusion
that referenced
this pull request
Nov 20, 2025
…ete or updated (apache#18799) <!-- 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 #. Dynamic filter pushdown in DataFusion currently lacks an API to determine when filters are "complete" (all contributing partitions have reported), this creates an ambiguity issue where it's impossible to differentiate between: 1. **Complete filter with no data**: Build side produced 0 rows, filter remains as placeholder `lit(true)`, no more updates coming 2. **Incomplete filter**: Filter is still being computed, updates are pending I think this could be especially useful when we want to make the filter updates progressively in the future. - Calls `mark_complete()` after barrier completes, regardless of whether bounds exist. - Exposes` is_complete() f`unction on the `DynamicFilterPhysicalExpr`. I didn't add any tests because the change is minimal , and comprehensive testing would require making the `DynamicFilterPhysicalExpr` public or running through the full optimizer pipeline. Exposing is_complete() function. (cherry picked from commit 7fa2a69)
LiaCastaneda
added a commit
to DataDog/datafusion
that referenced
this pull request
Nov 20, 2025
…ete or updated (apache#18799) (#60) <!-- 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 #. Dynamic filter pushdown in DataFusion currently lacks an API to determine when filters are "complete" (all contributing partitions have reported), this creates an ambiguity issue where it's impossible to differentiate between: 1. **Complete filter with no data**: Build side produced 0 rows, filter remains as placeholder `lit(true)`, no more updates coming 2. **Incomplete filter**: Filter is still being computed, updates are pending I think this could be especially useful when we want to make the filter updates progressively in the future. - Calls `mark_complete()` after barrier completes, regardless of whether bounds exist. - Exposes` is_complete() f`unction on the `DynamicFilterPhysicalExpr`. I didn't add any tests because the change is minimal , and comprehensive testing would require making the `DynamicFilterPhysicalExpr` public or running through the full optimizer pipeline. Exposing is_complete() function. (cherry picked from commit 7fa2a69)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
Rationale for this change
Dynamic filter pushdown in DataFusion currently lacks an API to determine when filters are "complete" (all contributing partitions have reported), this creates an ambiguity issue where it's impossible to differentiate between:
lit(true), no more updates comingI think this could be especially useful when we want to make the filter updates progressively in the future.
What changes are included in this PR?
mark_complete()after barrier completes, regardless of whether bounds exist.is_complete() function on theDynamicFilterPhysicalExpr.Are these changes tested?
I didn't add any tests because the change is minimal , and comprehensive testing would require making the
DynamicFilterPhysicalExprpublic or running through the full optimizer pipeline.Are there any user-facing changes?
Exposing is_complete() function.