大型超表上非常慢的连续聚合

Question

我正在使用最新的 docker 版本的 Postgres 14.3 和 Timescale 2.7.0。

我正在运行一些基准测试以确保 timescaledb 是适合我的客户的解决方案。 我有一个包含 5000 万行的超表。这些是按（大约）时间顺序插入的（大约来自于 4 个并行进程插入行的事实，但它们几乎同步地逐小时移动）。

我还有一个名为daily_view的连续聚合时间（按天聚合），以及一些分类标准，主要是客户ID和类型。共有 100,000 个唯一客户 ID，根据 this post，这应该不是问题，因为 TimescaleDB 处理高基数（或声称如此）。

一个简单的查询，例如：

select * from daily_vew limit 1;
...
Time: 39429.423 ms (00:39.429)

耗时超过 39 秒！

执行select count(*) from daily_view，耗时 1 分 43 秒。

奇怪的是，当我删除连续聚合的物化视图，并在 5000 万行的同一个超表上重新创建它时。完全相同的查询：

select * from daily_vew limit 1;
...
Time: 15.829 ms

只用了 15 毫秒！

select count(*) 耗时 9 秒。

显然，如果不能预先创建连续聚合并在数据进入时进行更新，那么连续聚合是没有用的。

为什么连续聚合的性能如此糟糕？ 为什么从头开始重新创建它的执行速度要快几个数量级？

Answer 1

连续聚合也是超表。你大概可以使用approximate_row_count，应该比原来的count函数快。