Hi all, I'd like to share a bug I recently found and the fix I am working on in the following PR: https://github.com/apache/iotdb/pull/19250
Problem The rate, irate, increase, and delta functions have ordered accumulators that require strictly ascending timestamps within each group. Their naive counterparts buffer all (time, value) samples and sort and validate them at final evaluation. The planner selected the ordered accumulator when the child’s ordering property proved the required order. However, for common table-scan plans, the child’s OrderingScheme does not include the native time column, even when an ascending scan is already producing rows in timestamp order. For example, assuming device_id is a TAG column that identifies one device: SELECT irate(s1, time) FROM t WHERE device_id = 'd1'; With an ascending scan, this query reads one device’s rows in timestamp order. But the planner left inputOrderedByTimeAscending as false, so the naive accumulator was selected and buffered the samples. Fix The PR supplements the existing ordering-property check with a scan-based guarantee. For a SINGLE aggregation over an ascending plain DeviceTableScanNode, it treats input as time ordered per group when only order-preserving Project or Filter nodes sit between the aggregation and scan, and either: The scan contains one device; or The grouping keys cover every TAG column, so each group belongs to at most one device. The rate function’s time argument must also resolve through projections to the scan’s native time column. Other cases, including descending scans, non-`SINGLE` steps, and unsupported scan types, continue to use the naive accumulator. Comments and review are welcome. If there is a case where the scan cannot guarantee per-group ordering, please point it out. Best regards, Xinqi Zhao
