inconsistent query behavior when handling future data

[localvar]

Describe your question

I generate 100M records into openGemini, the timestamp range is from 2023 to 2026.

when I execute select count(x) and select count(x) group by time(30d), I found the former takes future data into account, while the latter has not.

I cannot say which one is correct, but they are inconsistent.

IMHO, if openGemini allows user to insert future data then these data should be always counted, and I consider this is a feature.

[xiangyu5632]

What is your scenario for writing future data? Generally, this problem does not occur in O&M monitoring and IoT scenarios.
Considering the write performance, if we check each data record whether is greater than the current time, the performance is greatly affected.

[localvar]

What is your scenario for writing future data? Generally, this problem does not occur in O&M monitoring and IoT scenarios. Considering the write performance, if we check each data record whether is greater than the current time, the performance is greatly affected.

I have seen some corner cases, such as server time be adjusted to one year before intentionly. But this is not my point, my point is: the behavior should be consistent, if we allow future data, then we should always count them in.

[xiangyu5632]

I agree with you, but whether this changes the original semantics of the operator needs some more discussion.