invalidation engine clarification for CAGGs

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