Pwmj metrics accounting - #24956
Open
SubhamSinghal wants to merge 2 commits into
Open
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #24956 +/- ##
========================================
Coverage 81.61% 81.61%
========================================
Files 1124 1124
Lines 411978 412288 +310
Branches 411978 412288 +310
========================================
+ Hits 336236 336499 +263
- Misses 55936 55955 +19
- Partials 19806 19834 +28 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
Which issue does this PR close?
Part of #17427.
Rationale for this change
PiecewiseMergeJoinExec's metrics accounting had several gaps left over from earlier PRs in the epic:Left/Right/Full/Inner) never routedpoll_nextthroughBaselineMetrics::record_poll, sooutput_rows,output_bytes, andoutput_batchesstayed at0inEXPLAIN ANALYZEregardless of how many rows the join actually produced.join_timewas never measured on either the classic or existence-join stream — onlybuild_timewas timed, soelapsed_computeunderstated total operator cost for large probe sides.probe_hit_rate/avg_fanoutexist on the sharedBuildProbeJoinMetricsstruct (populated byHashJoinExec) but PWMJ never populated them, always showingN/A (0/0).What changes are included in this PR?
ClassicPWMJStream::poll_nextnow callsself.join_metrics.baseline.record_poll(poll), matching the existence-join stream.join_timeis timed around the actual comparison work:resolve_classic_joinand theProcessUnmatchedbitmap/take pass on the classic path;extreme_key+mark_matched_buffered_rowson the existence path.probe_hit_rate/avg_fanoutare populated for classic join, using the range size (buffered_len - buffer_idx) already computed at each match as the fanout.probe_hit_rateis populated for existence join: a streamed batch counts as a hit if its extreme key lowers the shared watermark, a miss otherwise.avg_fanoutis intentionally left unset for existence join — its watermark-based semantics don't have a natural per-row fanout equivalent.classic_join::tests::inner_join_records_output_and_probe_metricsandexistence_join::tests::probe_hit_rate_counts_batches_that_advance_the_watermark, both hand-derived and verified against actual runs.Are these changes tested?
Yes — two new unit tests
Are there any user-facing changes?
EXPLAIN ANALYZEon aPiecewiseMergeJoinExecplan now reports accurateoutput_rows/output_bytes/output_batches/join_time/probe_hit_rate/avg_fanoutinstead of zeros/N/A. No API or behavior change to query results.