标签: continuous-aggregates

我正在经历实时聚合而不是实时更新。我有什么遗漏的吗？

2.4.2使用当前 docker 镜像的版本的可重现示例timescale/timescaledb:latest-pg12：

CREATE TABLE data
(
    time  TIMESTAMPTZ      NOT NULL,
    value DOUBLE PRECISION NOT NULL
);

SELECT create_hypertable('data', 'time', chunk_time_interval => interval '1d');

INSERT INTO data (time, value)
VALUES ('2020-01-01', 100);

CREATE MATERIALIZED VIEW data_daily WITH (timescaledb.continuous)
AS
SELECT time_bucket('1 day', time) AS time,
       avg(value)                 AS avg,
       count(*)                   AS count
FROM data
GROUP BY 1;
ALTER MATERIALIZED VIEW data_daily SET (timescaledb.materialized_only = false);

现在，当我运行时，SELECT * FROM data_daily我得到了预期的结果：

time, avg, count
2020-01-01 00:00:00.000000, 100, …

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

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

我还有一个按daily_view时间调用的连续聚合（按天聚合），以及一些分类标准，主要是客户 ID 和类型。总共有 100,000 个唯一的客户 ID，根据这篇文章，这应该不是问题，因为 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 毫秒！

Aselect count(*)用了9秒。

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

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

I am trying to use the TimescaleDB extension to compute some continuous aggregates. I have this query which works fine:

SELECT distinct time_bucket('1 hour', entry_ts) as date_hour,
                type_id,
                entry_id,
                exit_id,
                count(*) OVER (partition by time_bucket('1 hour', entry_ts), entry_id, exit_id, type_id) AS total,
                ((count(*) over (partition by time_bucket('1 hour', entry_ts), entry_id, exit_id, type_id)) * 100)::numeric /
                (count(*) over (partition by time_bucket('1 hour', entry_ts), entry_id)) percentage_of_entry
FROM transits

When I try to put this inside a continuous aggregate materialized view, I get …

拥有包含几百万行的超表。我可以使用以下命令来选择它的大小：

SELECT pg_size_pretty( pg_total_relation_size('towns') );

我还有该超表的连续聚合：

WITH (timescaledb.continuous, timescaledb.materialized_only=true) AS
SELECT time_bucket(INTERVAL '1 minute', timestamp) AS bucket,
 /* random query */
FROM towns
GROUP BY bucket, town
WITH NO DATA;

我已刷新视图，数据按预期显示。然而，我似乎无法弄清楚这个新视图占用了多少空间。

SELECT pg_size_pretty( pg_total_relation_size('towns_income') );返回 0 字节，我知道这是不正确的。我认为也许 Total_relation_sizetowns会增加，但这似乎也是一样的。我错过了什么吗？我也尝试过hypertable_size但没有成功，因为 mv 从技术上讲并不是一个超表。