Repository navigation
fix: report LowerEqual cardinality effect for CoalescePartitionsExec with fetch - #26051
Conversation
…with fetch `CoalescePartitionsExec::cardinality_effect` returned `Equal` even when a fetch is set, so `PassthroughStatisticsProvider` matched it and copied the child statistics, discarding the fetch that the operator's own `statistics_from_inputs` applies. Return `LowerEqual` when a fetch is set, as `SortExec` and `SortPreservingMergeExec` already do.
e63ad80 to
a170053
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #26051 +/- ##
=======================================
Coverage 82.66% 82.66%
=======================================
Files 1147 1147
Lines 446357 446452 +95
Branches 446357 446452 +95
=======================================
+ Hits 368971 369055 +84
+ Misses 54997 54993 -4
- Partials 22389 22404 +15 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
rgbuilds
left a comment
There was a problem hiding this comment.
I traced the cardinality declaration through PassthroughStatisticsProvider and the operator statistics fallback. LowerEqual correctly prevents passthrough when fetch can reduce the output, allowing the existing fetch-aware calculation to cap the estimate.
The new tests cover both declaration branches and the resulting Exact(10) estimate from an Exact(1000) input. Restoring the previous Equal behavior makes the provider regression fail with Exact(1000). The focused physical-plan, optimizer, statistics, SQL logic, formatting, and Clippy checks pass locally. No blocking issues found.
|
Hey @nuno-faria, thanks a lot for the approval! Is there anything pending or we can merge this? |
|
I put it in the queue Tanks @nuno-faria and @asolimando and @rgbuilds |
Which issue does this PR close?
CoalescePartitionsExec::cardinality_effectreturnsEqualwhenfetchis set #26050.Rationale for this change
CoalescePartitionsExec::cardinality_effectreturnsCardinalityEffect::Equaleven whenfetchis set, although the operator can then produce fewer rows than its input. Code that relies oncardinality_effectgets the wrong answer, for examplePassthroughStatisticsProviderreports the input row count and drops the fetch.What changes are included in this PR?
CoalescePartitionsExec::cardinality_effectreturnsCardinalityEffect::LowerEqualwhenfetchis set, asSortExecandSortPreservingMergeExecalready do.What is the testing strategy for this PR?
cardinality_effectwith and withoutfetch.PassthroughStatisticsProviderno longer drops the fetch (Exact(10)instead ofExact(1000)).sqllogictestand the corephysical_optimizerintegration tests pass with no plan changes.Are there any user-facing changes?
No.
Disclaimer: I used AI to assist in the code generation, I have manually reviewed the output and it matches my intention and understanding.