apache/iotdb

Is your feature request related to a problem? IoTDB's Continuous Query (CQ) does not support calendar-month (or calendar-year) alignment for the EVERY execution interval and the RANGE time offsets. This makes it impossible to schedule a CQ that fires exactly at month boundaries — e.g. "run at the end of every month and aggregate over the whole natural month" — which is a common downsampling requirement. Because months have 28/29/30/31 days, the window length must be handled dynamically, so a fixed-day interval is not an adequate substitute. Current behavior Documentation The CQ documentation states that every_interval, start_time_offset, and end_time_offset support only the units ns, us, ms, s, m, h, d, w — mo (month) and y (year) are not listed: <every_interval> specifies the query execution time interval. We currently support the units of ns, us, ms, s, m, h, d, w ... Source: https://iotdb.apache.org/UserGuide/latest/User-Manual/Database-Programming.html Implementation Howeve

Search before asking I searched in the issues and found nothing similar. Motivation Description IoTDB should support Prometheus-compatible semantics for the PromQL rate(), irate(), increase(), and delta() functions on range vectors. The expected behavior should follow Prometheus: rate(v range-vector) returns the per-second average rate of increase over the selected range. irate(v range-vector) returns the per-second instant rate based on the last two samples in the selected range. increase(v range-vector) returns the total increase over the selected range. delta(v range-vector) returns the difference between the first and last values over the selected range. rate(), irate(), and increase() should be used with counters and should handle counter resets correctly. delta() should be used with gauges and should not apply counter-reset correction. rate(), increase(), and delta() should use all samples in the range and extrapolate to the range boundaries. irate() should use only the last

Search before asking I searched in the issues and found nothing similar. Motivation Motivation IoTDB already provides frequency-domain analysis capabilities in the tree model through UDFs such as fft/ifft in library-udf. However, users who work with the table model currently do not have an equivalent built-in or library-level way to run FFT/DFT analysis directly in SQL. For table-model workloads, frequency-domain analysis is useful for scenarios such as vibration monitoring, rotating machinery diagnosis, signal periodicity analysis, anomaly detection, and sensor data preprocessing. Users should be able to calculate Fourier transform results over a time-ordered numeric column, optionally partitioned by device/tag columns, without switching back to the tree model or exporting data to external tools. Solution Add FFT and DFT support for the IoTDB table model. A possible design is to provide table-model functions such as fft and dft that can process a numeric column ordered by time and

Motivation Reshaping data between wide and long form is a very common need in time-series analytics and reporting: PIVOT (long → wide): turn distinct values of a column (e.g. region, device_id, a status code) into separate columns, aggregating a measurement per cell. Great for building cross-tab/report-style result sets. UNPIVOT (wide → long): stack multiple measurement columns (e.g. temperature, humidity, pressure) into a (name, value) pair. This is especially natural for IoTDB, where the table model stores each measurement as its own column and users frequently want a normalized long format for downstream analytics or export. Today the table model has no PIVOT / UNPIVOT, so users must hand-write verbose CASE WHEN ... END aggregations (for pivoting) or long UNION ALL chains (for unpivoting). This proposes first-class PIVOT / UNPIVOT support, using DuckDB's syntax as the reference, since DuckDB offers both the SQL-standard form and a friendly simplified form, and is the most ergo

Search before asking I searched in the issues and found nothing similar. Motivation When performing complex aggregation queries, standard SQL requires users to explicitly repeat all non-aggregated columns from the SELECT list inside the GROUP BY clause. In real-world development and data analysis scenarios, this introduces several pain points: Tedious and Error-Prone Queries: When grouping by multiple dimensional attributes or tags (e.g., region, plant_id, device_model, status), users have to write these fields twice. If a user updates the SELECT list during iteration but forgets to update the GROUP BY list, it results in a syntax error. High Friction in Exploratory Data Analysis (EDA): Data analysts frequently add or remove dimension columns to observe metrics at different granularities. Synchronizing the SELECT and GROUP BY clauses for every minor adjustment breaks the analytical flow and reduces efficiency. Alignment with Modern Analytical Databases: Mainstream modern OLAP and a