Continuous Queries (CQ) in InfluxDB: Configuration, Syntax, Execution Timing, and Advanced RESAMPLE Options
This article explains InfluxDB's Continuous Queries feature, covering configuration settings, basic and advanced syntax, execution timing, data range handling, result storage, and the use of RESAMPLE clauses with practical examples and code snippets.
Continuous Queries (CQ) are a key feature of InfluxDB that automatically execute queries at regular intervals and store the results in a specified measurement.
Configuration
[continuous_queries]
enabled = true
log-enabled = true
query-stats-enabled = false
run-interval = "1s"The settings enable CQ, log its activity, disable query statistics, and set the check interval to one second.
Basic Syntax
CREATE CONTINUOUS QUERY <cq_name> ON <database_name>
BEGIN
<cq_query>
ENDThe query itself follows the standard SELECT format:
SELECT <function[s]>
INTO <destination_measurement>
FROM <measurement>
[WHERE <stuff>]
GROUP BY time(<interval>)[,<tag_key[s]>]Measurements are referenced as <database>.<RP>.<measurement>, but the default RP allows using just the measurement name.
Execution Timing
CQ execution times depend on the creation timestamp, the GROUP BY time() interval, and the Unix epoch (0). For example, a CQ created on 2019‑11‑05 with GROUP BY time(30d) first runs on 2019‑11‑10 and then every 30 days thereafter.
For shorter intervals, the schedule aligns with the epoch: a CQ with GROUP BY time(30s) created at 16:09:35 runs at 16:10:00, 16:10:30, 16:11:00, etc.
Data Range
Each execution processes data in the window [now() - GROUP BY time(), now()). For GROUP BY time(1h), the 8:00 run processes data from 7:00 (inclusive) to 8:00 (exclusive).
The WHERE clause can filter fields but its time condition is ignored.
Result Storage
The result always includes a time field set to the start of the processed window. Function results become fields: a single function yields a field named after the function; multiple functions produce function_field names.
SELECT mean("field")
INTO "result_measurement"
FROM "source_measurement"
GROUP BY time(30m)Result example:
time mean
2019-11-05T07:00:00Z 7For multiple fields:
SELECT mean("*")
INTO "result_measurement"
FROM "source_measurement"
GROUP BY time(30m) time mean_field1 mean_field2
2019-11-05T07:00:00Z 7 6.5Advanced Syntax (RESAMPLE)
CREATE CONTINUOUS QUERY <cq_name> ON <database_name>
RESAMPLE EVERY <interval> FOR <interval>
BEGIN
<cq_query>
END RESAMPLE EVERYdefines how often the CQ runs, while RESAMPLE FOR defines the time span of data each run processes.
Example with EVERY 30m:
CREATE CONTINUOUS QUERY "cq_every" ON "db"
RESAMPLE EVERY 30m
BEGIN
SELECT mean("field")
INTO "result_measurement"
FROM "source_measurement"
GROUP BY time(1h)
ENDWithout RESAMPLE, the CQ runs according to GROUP BY time() only.
Example with FOR 1h:
CREATE CONTINUOUS QUERY "cq_for" ON "db"
RESAMPLE FOR 1h
BEGIN
SELECT mean("field")
INTO "result_measurement"
FROM "source_measurement"
GROUP BY time(30m)
ENDWhen EVERY and FOR intervals differ, the CQ execution schedule follows EVERY, and the data window follows FOR, potentially splitting a single window into multiple points.
Both clauses can be combined, e.g.:
CREATE CONTINUOUS QUERY "cq_every_for" ON "db"
RESAMPLE EVERY 1h FOR 90m
BEGIN
SELECT mean("field")
INTO "result_measurement"
FROM "source_measurement"
GROUP BY time(30m)
ENDIn this case the CQ runs every hour, each run covering a 90‑minute window that is divided into three 30‑minute points.
Finally, CQs can only be created or dropped; they cannot be modified after creation.
System Architect Go
Programming, architecture, application development, message queues, middleware, databases, containerization, big data, image processing, machine learning, AI, personal growth.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
