From c5312e7613924a9bb1d9d55a4ada0a28bd1daa56 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fabr=C3=ADzio=20de=20Royes=20Mello?= Date: Fri, 24 Jan 2025 16:23:20 -0300 Subject: [PATCH] Update some API changes: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - `add_continuous_aggregate_policy`: added new optional argument `include_tiered_data` introduced by 2.18.0. - `refresh_continuous_aggregate`: added new optional argument `force` introduced by 2.18.0. Signed-off-by: Fabrízio de Royes Mello --- api/add_continuous_aggregate_policy.md | 3 ++- api/refresh_continuous_aggregate.md | 12 ++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/api/add_continuous_aggregate_policy.md b/api/add_continuous_aggregate_policy.md index 300078a822..ddaa253891 100644 --- 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,8 @@ 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 `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`.| +| `include_tiered_data` | BOOLEAN | Set true to read tiered data even if `timescaledb.enable_tiered_reads` is false. Defaults to `TRUE`. | ### Returns diff --git a/api/refresh_continuous_aggregate.md b/api/refresh_continuous_aggregate.md index 2d777e992c..916469d309 100644 --- 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. +### Optional arguments + +|Name|Type|Description| +|-|-|-| +| `force` | BOOLEAN | Force the refresh even if the window range is already refreshed. Default to `FALSE`.| + ### Sample usage Refresh the continuous aggregate `conditions` between `2020-01-01` and @@ -93,6 +99,12 @@ END $$; ``` +Forcing the refresh of the continuous aggregate `conditions` between `2020-01-01` and +`2020-02-01` exclusive even if it is already refreshed. + +```sql +CALL refresh_continuous_aggregate('conditions', '2020-01-01', '2020-02-01', TRUE); +``` [modify-parameters]: /use-timescale/:currentVersion/configuration/customize-configuration/ [create_materialized_view]: /api/:currentVersion:/continuous-aggregates/create_materialized_view/