Skip to content

rfc: distributed dynamic filtering#553

Open
jayshrivastava wants to merge 14 commits into
branch-55from
js/dynamic-filtering-design
Open

rfc: distributed dynamic filtering#553
jayshrivastava wants to merge 14 commits into
branch-55from
js/dynamic-filtering-design

Conversation

@jayshrivastava

@jayshrivastava jayshrivastava commented Jul 14, 2026

Copy link
Copy Markdown
Collaborator

@jayshrivastava
jayshrivastava changed the base branch from main to branch-55 July 14, 2026 19:12
@jayshrivastava jayshrivastava changed the title Js/dynamic filtering design rfc: distributed dynamic filtering Jul 14, 2026
Comment thread rfcs/1-distributed-dynamic-filtering.md
@jayshrivastava jayshrivastava changed the title rfc: distributed dynamic filtering [WIP] rfc: distributed dynamic filtering Jul 20, 2026
@jayshrivastava
jayshrivastava marked this pull request as ready for review July 22, 2026 19:49
@jayshrivastava jayshrivastava changed the title [WIP] rfc: distributed dynamic filtering rfc: distributed dynamic filtering Jul 22, 2026

@gabotechs gabotechs left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This is looking very good! I really do not have any major comments, this seems to be going in the right direction.

Comment on lines +268 to +272
The proposed change is to implement dynamic filtering similarly to Trino.

1. During execution, the dynamic filter producers (`HashJoinExec`, `SortExec`, `AggregateExec`) will send dynamic filter updates to the coordinator.
2. The coordinator will union / merge the dynamic filter updates from all workers.
3. The coordinator will send the unioned / merged dynamic filter updates to the consumers (`DataSourceExec`).

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

👍 Sounds good, with the current infrastructure, I don't think it would be terrible difficult to do this

- Less overhead than ORing

Cons:
- Is brittle. What if we have to support non-range and non-IN-LIST expressions? It would be nice if dynamic filters in vanilla datafusion natively implemented a `merge` or `union` operation

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Why do you think it's brittle? For merging, I imagine you can just rely on Arrow comparison kernels for deduping IN LIST expressions.


// Read Updates
pub fn current(&self) -> Result<Arc<dyn PhysicalExpr>>
pub(crate) fn subscribe(&self) -> DynamicFilterSubscription

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

🤔 subscribe not being public might be a problem.


#### Options 1 & 2: Support new APIs In Vanilla DataFusion

See https://github.com/apache/datafusion/issues/23814

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

apache/datafusion#23814 seems to be evolving in a good direction, and people seem engaged in the discussion, so I'd lean towards using whatever comes out of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants