Hi all,

This email describes the recent work to add dynamic interval macro support to 
IoTDB table-model SQL queries in the Grafana plugin. The change has been 
implemented, reviewed, and merged in PR 
https://github.com/apache/iotdb-extras/pull/122.


**Background**


Grafana calculates a query interval at runtime based on the selected dashboard 
time range and query settings. When users change the time range, the interval 
may become smaller or larger so that the returned data contains an appropriate 
number of points.


If an IoTDB SQL query always uses a fixed interval such as 15s or 120s, the 
result may contain too many or too few points after the time range changes. 
This can cause excessive data density, insufficient resolution, and 
inconsistent panel behavior.


Grafana provides the `$__interval` and `$__interval_ms` macros for data sources 
to use the runtime query interval.


**Problem**


The IoTDB Grafana plugin did not expand these interval macros in table-model 
SQL queries. As a result, SQL statements using date_bin or HOP could continue 
to use a fixed window or slide interval instead of the interval selected by 
Grafana.


When the dashboard time range changes, the fixed interval may no longer match 
Grafana's expected query interval. The panel may then display an overly dense 
or overly sparse set of data points.


The standard Grafana meaning of `$__interval_ms` is milliseconds, independent 
of the IoTDB server timestamp precision. The implementation therefore needs to 
preserve this contract and avoid introducing data-source-specific scaling.


**Scope**


This change is limited to backend expansion of Grafana interval macros in IoTDB 
table-model SQL queries. It does not change date_bin or HOP origin semantics, 
rate/increase window semantics, or query planner aggregation behavior.


Dashboard SQL statements must explicitly use `$__interval` or `$__interval_ms` 
to benefit from Grafana's runtime interval. Existing SQL statements with fixed 
interval values continue to use those fixed values.


Best regards,
Xinqi Zhao

Reply via email to