chore: quickly publish caggs updates (#3814)

timescale · Feb 6, 2025 · 88c19b9 · 88c19b9
1 parent 7490bad
commit 88c19b9
Show file tree

Hide file tree

Showing 3 changed files with 16 additions and 2 deletions.
diff --git a/_partials/_integration-prereqs.md b/_partials/_integration-prereqs.md
@@ -6,4 +6,4 @@ Before integrating:
 
 [create-service]: /getting-started/:currentVersion:/services/
 [enable-timescaledb]: /self-hosted/:currentVersion:/install/
-[connection-info]: /use-timescale/:currentVersion:/integrations/find-connection-details/
+[connection-info]: /use-timescale/:currentVersion:/integrations/find-connection-details/
diff --git a/api/add_continuous_aggregate_policy.md b/api/add_continuous_aggregate_policy.md
@@ -24,7 +24,6 @@ policies that you set or the policies that already exist, see
 |`end_offset`|INTERVAL or integer|End of the refresh window as an interval relative to the time when the policy is executed. `NULL` is equivalent to `MAX(timestamp)` of the hypertable.|
 |`schedule_interval`|INTERVAL|Interval between refresh executions in wall-clock time. Defaults to 24 hours|
 |`initial_start`|TIMESTAMPTZ|Time the policy is first run. Defaults to NULL. If omitted, then the schedule interval is the intervalbetween the finish time of the last execution and the next start. If provided, it serves as the origin with respect to which the next_start is calculated |
-|`timezone`|TEXT|A valid time zone. If `initial_start` is also specified, subsequent executions of the refresh policy will be aligned on its initial start. However, daylight savings time (DST) changes may shift this alignment. Set to a valid time zone if this is an issue you want to mitigate. If omitted, UTC bucketing is performed. Defaults to `NULL`.|
 
 The `start_offset` should be greater than `end_offset`.
 
@@ -49,6 +48,9 @@ about how continuous aggregates use real-time aggregation, see the
 |Name|Type|Description|
 |-|-|-|
 |`if_not_exists`|BOOLEAN|Set to `true` to issue a notice instead of an error if the job already exists. Defaults to false.|
+|`timezone`|TEXT|A valid time zone. If you specify `initial_start`, subsequent executions of the refresh policy are aligned on `initial_start`. However, daylight savings time (DST) changes may shift this alignment. If this is an issue you want to mitigate, set `timezone` to a valid time zone. Default is `NULL`, [UTC bucketing](https://docs.timescale.com/use-timescale/latest/time-buckets/about-time-buckets/) is performed.|
+| `include_tiered_data` | BOOLEAN | Enable/disable reading tiered data. This setting helps override the current settings for the`timescaledb.enable_tiered_reads` GUC. The default is NULL i.e we use the current setting for `timescaledb.enable_tiered_reads` GUC  | |
+
 
 ### Returns
 

diff --git a/api/refresh_continuous_aggregate.md b/api/refresh_continuous_aggregate.md
@@ -62,6 +62,12 @@ not take place when buckets are materialized with no data changes or with
 changes that only occurred in the secondary table used in the JOIN.
 </Highlight>
 
+### Optional arguments
+
+|Name|Type|Description|
+|-|-|-|
+| `force` | BOOLEAN | Force refresh every bucket in the time range between `window_start` and `window_end`, even when the bucket has already been refreshed. This can be very expensive when a lot of data is refreshed. Default is `FALSE`.|
+
 ### Sample usage
 
 Refresh the continuous aggregate `conditions` between `2020-01-01` and
@@ -93,6 +99,12 @@ END
 $$;
 ```
 
+Force the  `conditions` continuous aggregate to refresh between `2020-01-01` and
+`2020-02-01` exclusive, even if the data has already been refreshed.
+
+```sql
+CALL refresh_continuous_aggregate('conditions', '2020-01-01', '2020-02-01', force => TRUE);
+```
 
 [modify-parameters]: /use-timescale/:currentVersion/configuration/customize-configuration/
 [create_materialized_view]: /api/:currentVersion:/continuous-aggregates/create_materialized_view/