PDGGK commented on issue #16985: URL: https://github.com/apache/iotdb/issues/16985#issuecomment-5180693980
Following up on this one, since it has been quiet since July and the actionable half is now resolved on master. **On the reported behaviour.** @Wei-hao-Li's ruling above settles it: an aggregate over no input returns NULL (except `count`), so one all-NULL row after deleting the data is correct, not a bug. I had a PR open in the opposite direction (#17411) that suppressed that row; I closed it once that was clear, and the Trino comparison in that thread is what convinced me. **On "the fix should focus on what causes the empty result".** That turned out to be a different, sibling case in the same report: the *tag with no data* one, where the query returned **zero rows** rather than one NULL row. That is fixed on master by #18267 (merged 2026-07-24). The two are genuinely different code paths, which is why only one of them moved: - **Device with data deleted** — deleting rows does not remove the device. `DELETE DEVICES` is a separate statement with its own grammar rule (`RelationalSql.g4:377-378`) and its own AST node, and `deviceEntries` is resolved from the schema rather than from the data — the fetch is literally `fetchDeviceSchemaForDataQuery` (`TableDeviceSchemaFetcher:216`, reached via `TableMetadataImpl:1686`). So the schema entry survives, `deviceEntries` is non-empty, `canUseLastCacheOptimize` still applies, and planning is byte-for-byte what it was before #18267. It returns the one NULL row, as intended. - **Device never written** — `deviceEntries` resolves empty. Before the fix that reached `LastQueryAggTableScanOperator`, whose `hasNext()` is `outputDeviceIndex < allDeviceCount`, i.e. `0 < 0` → zero rows. #18267 routes the no-device, no-grouping-key case to the default aggregation operator instead, whose `hasNext()` is driven by the pre-seeded `TimeRange(MIN_VALUE, MAX_VALUE)`, so it emits one row and the aggregators write NULL. So the two cases now agree, and both match the rule quoted above. **One caveat for anyone hitting this on a release.** #18267 is on master only -- no released tag contains it -- so 2.0.5 through 2.0.10 still show the zero-row behaviour for a never-written device. Worth knowing before testing against a release build. @meng-easonZhou — the expectation in the report (no rows after a delete) is the part that was ruled against; if the deleted-device case is still returning something other than a single NULL row for you on master, that would be a separate finding and worth reopening with the exact DDL and query. -- 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]
