feat: re-expose the embedder public API a distributed driver needs#29
Merged
Conversation
This was referenced Jun 30, 2026
deb340e to
02ff23b
Compare
328e142 to
3439f34
Compare
3d4c5d8 to
c46b2e3
Compare
f07eb09 to
61552ba
Compare
An out-of-crate driver collects worker metrics for its EXPLAIN rendering, so it needs the metrics store with a public insert and a no-gRPC decode_task_metrics.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR re-exposes the worker-metrics API an out-of-crate driver needs, which datafusion-contrib#512 removed. It stacks on the transport-completion PR (#27).
What
DistributedExec::metrics_store()+ publicMetricsStore/MetricsStore::insert: so a driver can collect worker metrics out of crate.decode_task_metrics: the worker-metrics proto to plainTaskMetricsdecode.Why
datafusion-contrib#512 dropped these as not-transport-concerns, with "what's worth making public in a follow up." This is that follow-up: the shm transport returns metrics over the mesh rather than over the
coordinator_channelreturn stream, so its embedder files the decoded frames into the executed plan's store itself before the per-task EXPLAIN rewrite.Please note that this surface would disappear entirely if the shm channel delivered
TaskMetricsthrough itscoordinator_channelreturn stream like gRPC does; that is a candidate follow-up, and this PR is the smaller cut until then.