TimescaleDB大hypertable上continuous aggregate性能极慢问题

预创建的连续聚合（Continuous Aggregate, 下简称cagg）查询性能极差的核心原因 #

• 底层物化表严重碎片化：TimescaleDB 2.7.0版本的cagg增量刷新逻辑，是跟随写入节奏对命中的时间窗口做小批量聚合写入。测试场景中4个并行进程持续按小时粒度推进写入，cagg的刷新任务会将天级聚合结果拆成大量KB级的小片段零散写入物化表，不会自动做块合并和存储整理。原本10万客户*时间跨度对应的天级聚合结果仅百万级有效行，碎片化后会产生数十万个离散存储的堆页、碎片化索引条目，查询时会触发大量随机IO，还要在扫描过程中对重叠碎片的重复聚合结果做去重计算，开销陡增。
• 统计信息严重失真：小批量增量刷新cagg时，PostgreSQL不会自动触发对底层物化表的统计信息收集，优化器拿到的行数估算、数据分布、索引选择度信息和实际存储偏差可达数十倍，直接生成低效执行计划：例如limit 1这类本可以通过索引快速定位返回的查询，会被错误引导为全表扫描。
• 失效tuple残留：写入场景存在进程间的极小时序偏差，2.7版本cagg遇到跨窗口的乱序写入时，会将对应时间窗口的旧聚合结果标记为失效但不会立即物理清理，这些死tuple会持续占用存储页，查询扫描时需要额外读取并过滤这些无效数据，进一步放大扫描开销。

删除重建后性能出现数量级提升的原因 #

• 全量批量写入无存储碎片：删除cagg后重建时，TimescaleDB会直接对已经稳定落盘的全量5000万行源hypertable做一次性批量聚合，聚合结果会按时间+维度列的最优排序顺序紧凑写入物化表，页填充率达到默认阈值，无离散小碎片，扫描时以顺序IO为主，IO效率比扫碎片高2~3个数量级。
• 统计信息准确：cagg全量重建完成后，系统会自动触发对物化表的analyze操作，优化器能拿到准确的行数、数据分布、索引统计信息，可生成最优执行计划：例如select * from daily_view limit 1可以直接通过主键索引取第一条记录立即返回，不需要扫描全量数据。
• 无无效数据残留：全量重建生成的物化表只包含最新的有效聚合结果，没有历史增量刷新留下的死tuple，不存在额外的无效数据过滤开销。

• 若为一次性历史数据导入场景，建议等全量数据写入完成后再创建cagg，避免边写边刷产生的碎片。
• 针对持续写入的生产场景，不要将cagg的刷新窗口设置得过小（建议不小于1小时），降低小批量写入产生的碎片频率；定期在业务低峰期对历史时间范围的cagg执行refresh_continuous_aggregate重刷，配合VACUUM FULL整理物化表碎片。
• 配置定时任务定期对cagg底层物化表执行ANALYZE，保证优化器统计信息准确，避免走错执行计划。

内容的提问来源于stack exchange，提问作者jbx