Timescale Cloud：性能、扩展、企业级
自托管产品
MST
创建一个策略，自动刷新连续聚合。要查看您设置的或已存在的策略，请参阅信息视图。
| 名称 | 类型 | 描述 |
|---|---|---|
continuous_aggregate | REGCLASS | 要添加策略的连续聚合 |
start_offset | INTERVAL 或 integer | 刷新窗口的开始，表示为相对于策略执行时间的间隔。NULL 等同于超表的 MIN(timestamp)。 |
end_offset | INTERVAL 或 integer | 刷新窗口的结束，表示为相对于策略执行时间的间隔。NULL 等同于超表的 MAX(timestamp)。 |
schedule_interval | INTERVAL | 刷新执行之间的时间间隔（挂钟时间）。默认为 24 小时 |
initial_start | TIMESTAMPTZ | 策略首次运行的时间。默认为 NULL。如果省略，则调度间隔是上次执行的结束时间与下次开始时间之间的间隔。如果提供，它将作为计算 next_start 的起始点。 |
start_offset 应该大于 end_offset。
您必须根据超表时间列的类型，以不同方式指定 start_offset 和 end_offset 参数
- 对于时间列为
TIMESTAMP、TIMESTAMPTZ和DATE类型的超表，将偏移量设置为INTERVAL类型。 - 对于基于整数时间戳的超表，将偏移量设置为
INTEGER类型。
重要提示
虽然可以将 end_offset 设置为 NULL，但不建议这样做。要在查询中包含 end_offset 和当前时间之间的数据，请启用实时聚合。
| 名称 | 类型 | 描述 |
|---|---|---|
if_not_exists | BOOLEAN | 如果任务已存在，设置为 true 则发出通知而非错误。默认为 false。 |
timezone | TEXT | 有效时区。如果您指定 initial_start，刷新策略的后续执行将与 initial_start 对齐。但是，夏令时 (DST) 变更可能会导致此对齐发生偏移。如果您想缓解此问题，请将 timezone 设置为有效时区。默认为 NULL，执行 UTC 分桶。 |
include_tiered_data | BOOLEAN | 启用/禁用分层数据读取。此设置有助于覆盖 timescaledb.enable_tiered_reads GUC 的当前设置。默认为 NULL，即我们使用 timescaledb.enable_tiered_reads GUC 的当前设置。 |
buckets_per_batch | INTEGER | 一个*批次*要刷新的桶数量。此值乘以 CAgg 桶宽度以确定批次范围的大小。默认值为 0，表示单批次执行。不允许小于 0 的值。 |
max_batches_per_execution | INTEGER | 限制策略执行时运行的最大批次数量。如果仍有批次，它们将在策略下次运行时处理。默认值为 10，每个任务最多处理 10 个批次。设置为 0 表示批次数量无限制。不允许小于 0 的值。 |
重要提示
将 buckets_per_batch 设置为大于零，意味着刷新窗口将按 桶宽度 * 每批次桶数 的批次进行拆分。例如，一个给定的连续聚合，其 桶宽度 为 1 day，buckets_per_batch 为 10，则刷新处理的批次大小为 10 days。因为每个 批次 都是一个独立的事务，所以分批执行策略可以在整个任务执行完成之前让数据对用户可见。批次按从最新数据到最旧数据的顺序进行处理。
| 列 | 类型 | 描述 |
|---|---|---|
job_id | INTEGER | 为实现此策略而创建的 TimescaleDB 后台任务 ID |
添加一个策略，每小时刷新上个月的数据，同时将最近一小时的数据排除在聚合之外。出于性能原因，我们建议您排除写入量大的桶。
SELECT add_continuous_aggregate_policy('conditions_summary',start_offset => INTERVAL '1 month',end_offset => INTERVAL '1 hour',schedule_interval => INTERVAL '1 hour');
关键词
在此页发现问题？报告问题
或 在 GitHub 编辑此页面
in GitHub.