-
Notifications
You must be signed in to change notification settings - Fork 1
Address remaining TODOs after custom executor implementation #14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@coderabbitai summary |
✅ Actions performedSummary regeneration triggered. |
📝 WalkthroughWalkthroughThis PR renames the protobuf TaskValue to MaterializedTaskValue (removing the Plan variant) and updates all Rust conversions/usages to use the new materialized type. It removes Plan serialization/deserialization paths and associated fingerprinting for Plan values. Separately, the expression compiler entrypoint and nearly all compile_* functions were changed from synchronous to asynchronous (using async recursion), and all callers were updated to await compile results. Minor async fixes applied in task/runtime/transform call sites and tests. Sequence Diagram(s)sequenceDiagram
participant Caller
participant ProtoLayer as Protobuf
participant Serializer as Serializer
participant TaskGraph as TaskGraph
Note over ProtoLayer,Serializer #DDEBF7: MaterializedTaskValue replaces TaskValue (no Plan)
Caller->>Serializer: build Task with Value
Serializer->>ProtoLayer: ProtoMaterializedTaskValue::try_from(&value)
ProtoLayer-->>Serializer: bytes (scalar|table)
Serializer->>TaskGraph: embed MaterializedTaskValue in Task proto
TaskGraph-->>Caller: serialized Task
sequenceDiagram
participant Requester
participant Compile as compile (async)
participant Variants as compile_* (async)
participant Eval as eval callers
Requester->>+Compile: compile(expr,...).await
Compile->>+Variants: compile_xxx(...).await
Variants->>Variants: await nested compile(...) calls
Variants-->>-Compile: Result<Expr>
Compile-->>-Requester: Result<Expr>
Note over Eval,Compile #F7F6DD: Call sites updated to use .await? when invoking compile
Possibly related PRs
Suggested reviewers
Pre-merge checks❌ Failed checks (4 warnings)
✅ Passed checks (1 passed)
Comment |
ade982e to
b1f5d1d
Compare
|
@coderabbitai full review but no yapping please, only highlight big issues re security, correctness, or performance |
|
@OlegWock: Triggering full review focused on security, correctness, and performance issues only. ✅ Actions performedFull review triggered. |
mfranczel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; with a few non-blocking comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Consider adding a test for plan materialization
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That will be in separate PR along with other tests for custom executor
@coderabbitai ignore
Contributes to BLU-4774
There are two changes lumped together in this pull request.
First, we update code to use
MaterializedTaskValuewhere it makes more sense instead of justTaskValue, becauseTaskValuecan have a variantPlanwhich is not serializable in the current implementation and current version of DataFusion. I.e. we can't serialize it to protobuf to send in messages. Those protofbuf definitions were updated toMaterializedTaskValuewhich can send either a scalar or table. We didn't send plan across process boundaries anyway, so this change doesn't break anything.Second change is an update to expression compilation to make it asynchronous. Some expressions might need access to data. This data might not be materialized yet. To materialize this data, a custom executor is used and materialization is an asynchronous function. To call it, we needed to make the whole chain of compilation asynchronous. All call sites which compiled those expressions were already async, so we didn't have to do a lot of changes. But it's just quite a bit of adding
asyncandawaitwhere necessary.Summary by CodeRabbit
Refactor
Documentation