Ensure your table is a hypertable: `SELECT create_hypertable('sensor_data', 'time');` if not already done.
Create a continuous aggregate materialized view: `CREATE MATERIALIZED VIEW sensor_hourly WITH (timescaledb.continuous) AS SELECT time_bucket('1 hour', time) AS bucket, device_id, AVG(value) AS avg_val FROM sensor_data GROUP BY bucket, device_id;`
Add a refresh policy to keep the aggregate up to date: `SELECT add_continuous_aggregate_policy('sensor_hourly', start_offset => INTERVAL '3 hours', end_offset => INTERVAL '1 hour', schedule_interval => INTERVAL '30 minutes');`
Query the aggregate as you would any view: `SELECT * FROM sensor_hourly WHERE bucket > NOW() - INTERVAL '24 hours' ORDER BY bucket;`
Inspect policy jobs with `SELECT * FROM timescaledb_information.jobs;` and check for errors in `timescaledb_information.job_stats`.
Known gotchas
`end_offset` must be greater than zero to avoid refreshing the real-time boundary, where data may still be ingesting; a 1-hour end_offset is a safe default.
Continuous aggregates do not support all SQL constructs — DISTINCT, subqueries in GROUP BY, and certain window functions are not allowed in the aggregate definition.
Dropping the source hypertable requires dropping dependent continuous aggregates first; plan schema changes accordingly.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp