timescaledb 连续聚合不支持 lag() 等窗口函数，因其仅存储预计算聚合结果而不保留原始行数据及顺序信息，无法执行跨时间桶的行间比较；替代方案是在查询层对已刷新的连续聚合视图使用 lag() 开窗。
TimescaleDB 的连续聚合（continuous aggregate）本身不支持 LAG() 这类窗口函数，这是由其物化机制决定的——它只保存预计算的聚合结果，而非原始行数据，因此无法执行跨行比较操作。
为什么 continuous aggregate 中不能用 LAG()
连续聚合在底层是基于物化视图实现的，每次刷新时只将新到达的数据按时间分组做 GROUP BY time_bucket 后聚合（如 AVG、MAX），不保留明细或顺序信息。而 LAG() 需要访问相邻时间桶的聚合结果，但这些“前一个桶”的值可能尚未被刷新、已被合并、或根本不在当前刷新窗口内。
常见报错类似：
ERROR: window functions are not allowed in continuous aggregate definitions
替代方案：用 refresh policy 控制数据新鲜度
虽然不能直接用 LAG()，但可通过合理设置刷新策略，让连续聚合的结果尽可能“及时”，从而在应用层或后续查询中安全地做前后桶对比：
- 刷新间隔（refresh_interval）：决定多久触发一次增量更新，默认为
30m；设太短会增加 I/O 和锁开销，设太长会导致数据滞后 - 刷新窗口（refresh_window）：定义每次刷新覆盖的时间范围（如
'1 day'），必须 ≥ 刷新间隔，否则会出现空洞 - 初始延迟（start_offset）：可设为负值（如
'-5m'），让聚合从最近数据开始，避免冷启动空白期
如何在查询中模拟“前一周期”值
若需对比当前桶与上一个桶的聚合值（例如环比变化），推荐以下方式：
- 在查询连续聚合视图时，用
LAG()对该视图本身开窗（不是在定义中用）——只要视图已刷新且数据连续，就合法 - 确保查询时间范围覆盖至少两个完整时间桶，并按
time_bucket排序 - 示例：
SELECT bucket, avg_value, LAG(avg_value) OVER (ORDER BY bucket) AS prev_avg, (avg_value - LAG(avg_value) OVER (ORDER BY bucket)) / NULLIF(LAG(avg_value) OVER (ORDER BY bucket), 0) AS pct_change FROM your_cont_agg WHERE bucket > now() - INTERVAL '2 hours' ORDER BY bucket;监控 lag 与实际延迟的小技巧
连续聚合的“lag”通常指最新原始数据与最新聚合结果之间的时间差。可用以下方式评估：
- 查原始表最大时间戳：
SELECT MAX(time) FROM your_hypertable; - 查连续聚合视图最大时间戳：
SELECT MAX(bucket) FROM your_cont_agg; - 二者之差即为当前端到端延迟；若差值明显大于
refresh_interval，说明刷新卡顿或资源不足 - 检查后台刷新作业：
SELECT * FROM timescaledb_information.continuous_aggregate_stats;
