From 85a807a01df7ae5fbfe33b66d38784e09fc60654 Mon Sep 17 00:00:00 2001 From: atovpeko Date: Fri, 7 Nov 2025 12:12:39 +0200 Subject: [PATCH 1/2] invalidation engine clarification --- .../about-continuous-aggregates.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/use-timescale/continuous-aggregates/about-continuous-aggregates.md b/use-timescale/continuous-aggregates/about-continuous-aggregates.md index 29697a5de8..401a79a606 100644 --- a/use-timescale/continuous-aggregates/about-continuous-aggregates.md +++ b/use-timescale/continuous-aggregates/about-continuous-aggregates.md @@ -260,11 +260,17 @@ materialization threshold forward in time. This ensures that the threshold lags behind the point-in-time where data changes are common, and that most INSERTs do not require any extra writes. -When data older than the invalidation threshold is changed, the maximum and -minimum timestamps of the changed rows is logged, and the values are used to -determine which rows in the aggregation table need to be recalculated. This -logging does cause some write load, but because the threshold lags behind the -area of data that is currently changing, the writes are small and rare. +When data older than the invalidation threshold is changed, each mutation +operation logs the minimum and maximum timestamps of the rows it modified. +The continuous aggregate then identifies which complete time buckets contain +these modified rows. Only those specific buckets are recalculated during refresh. + +For example, if one operation modifies rows in the 10:00 bucket and another +modifies rows in the 15:00 bucket, only those two buckets are recalculated. The +buckets in between (11:00, 12:00, 13:00, 14:00) are not affected. + +This logging does cause some write load. However, the threshold lags behind the +area of data that is currently changing, so the writes are small and rare. [cagg-mat-hypertables]: /use-timescale/:currentVersion:/continuous-aggregates/materialized-hypertables [cagg-window-functions]: /use-timescale/:currentVersion:/continuous-aggregates/create-a-continuous-aggregate/#use-continuous-aggregates-with-window-functions From f2099d5b61648a8227958651a16ce79522996f2a Mon Sep 17 00:00:00 2001 From: atovpeko Date: Wed, 12 Nov 2025 12:28:24 +0200 Subject: [PATCH 2/2] update on review --- .../about-continuous-aggregates.md | 20 +++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/use-timescale/continuous-aggregates/about-continuous-aggregates.md b/use-timescale/continuous-aggregates/about-continuous-aggregates.md index 401a79a606..b188096d7c 100644 --- a/use-timescale/continuous-aggregates/about-continuous-aggregates.md +++ b/use-timescale/continuous-aggregates/about-continuous-aggregates.md @@ -260,14 +260,18 @@ materialization threshold forward in time. This ensures that the threshold lags behind the point-in-time where data changes are common, and that most INSERTs do not require any extra writes. -When data older than the invalidation threshold is changed, each mutation -operation logs the minimum and maximum timestamps of the rows it modified. -The continuous aggregate then identifies which complete time buckets contain -these modified rows. Only those specific buckets are recalculated during refresh. - -For example, if one operation modifies rows in the 10:00 bucket and another -modifies rows in the 15:00 bucket, only those two buckets are recalculated. The -buckets in between (11:00, 12:00, 13:00, 14:00) are not affected. +When data older than the invalidation threshold is changed, each transaction +logs the minimum and maximum timestamps of the rows it modified. +The continuous aggregate then identifies which complete time buckets are affected +based on this per-transaction tracking. The range of buckets that are recalculated +depends on transaction boundaries: + +* If you modify rows in the 10:00 bucket and rows in the 15:00 bucket within a + **single transaction**, all buckets from 10:00 to 15:00 (including intermediate + buckets 11:00, 12:00, 13:00, and 14:00) are recalculated during refresh. +* If you modify rows in the 10:00 bucket in one transaction and rows in the 15:00 + bucket in a **separate transaction**, only the 10:00 and 15:00 buckets are + recalculated. The intermediate buckets (11:00, 12:00, 13:00, 14:00) are not affected. This logging does cause some write load. However, the threshold lags behind the area of data that is currently changing, so the writes are small and rare.