asolimando opened a new issue, #26050: URL: https://github.com/apache/datafusion/issues/26050
### Describe the bug `CoalescePartitionsExec::cardinality_effect` always returns `CardinalityEffect::Equal`, which is documented as "the operator is guaranteed to produce exactly one row for each input row". When `fetch` is set, the operator can produce fewer rows than its input, so it should return `CardinalityEffect::LowerEqual`, as `SortExec` and `SortPreservingMergeExec` already do when they have a fetch. Any code that relies on `cardinality_effect` gets the wrong answer for this operator. For example, `PassthroughStatisticsProvider` returns the input statistics unchanged for operators with `CardinalityEffect::Equal`, so a `CoalescePartitionsExec` with `fetch = 10` over 1000 rows reports `Exact(1000)` instead of `Exact(10)`. ### To Reproduce ```rust let plan = CoalescePartitionsExec::new(input).with_fetch(Some(10)); assert!(matches!(plan.cardinality_effect(), CardinalityEffect::LowerEqual)); // fails: Equal ``` ### Expected behavior `cardinality_effect` returns `CardinalityEffect::LowerEqual` when `fetch` is set, and `CardinalityEffect::Equal` otherwise. ### Additional context Other readers of `cardinality_effect` are the physical optimizer rules `sort_pushdown`, `topk_aggregation` and `limit_pushdown_past_window`. I did not find a query that returns wrong results because of this, and no `sqllogictest` plan changes with the fix. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
