Use ALTER DYNAMIC TABLE to modify a dynamic table's refresh behavior, computing resources, query definition, and table properties. Only the operations described in this topic are supported.
Syntax overview
The following statements summarize all supported ALTER DYNAMIC TABLE operations. Detailed usage, parameters, and version constraints are covered in each section below.
-- Pause or resume auto-refresh
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (auto_refresh_enable = false | true);
-- Modify freshness (V3.1+ only)
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (freshness = '<num> {minutes | hours}');
-- Modify computing resource (V4.0.7+)
ALTER [DYNAMIC] TABLE [IF EXISTS] [<schema>.]<table_name> SET (['local' | 'serverless' | '<warehouse_name>']);
ALTER DYNAMIC TABLE [IF EXISTS] [<schema>.]<table_name> SET (auto_refresh_guc_hg_experimental_serverless_computing_required_cores = '<num>');
-- Modify refresh mode
ALTER DYNAMIC TABLE <schema_name>.<table_name> SET (auto_refresh_mode = '<full/auto>'); -- V3.1+
ALTER DYNAMIC TABLE <schema_name>.<table_name> SET (refresh_mode = 'full'); -- V3.0
-- Modify active partition time range (V3.1+ only)
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (auto_refresh_partition_active_time = '<num> {minutes | hours | days}');
-- Modify query definition (V3.1.18+)
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> AS <query>;
-- Rename the table (V3.1.20+)
ALTER DYNAMIC TABLE [IF EXISTS] <table_name> RENAME TO <new_name>;
-- Modify dictionary encoding, bitmap index, TTL, and schema
ALTER DYNAMIC TABLE [<schema_name>.]<table_name> SET (dictionary_encoding_columns = '[<columnName>{:[on|off|auto]}[,...]]');
ALTER DYNAMIC TABLE [<schema_name>.]<table_name> SET (bitmap_columns = '[<columnName>{:[on|off]}[,...]]');
ALTER DYNAMIC TABLE [<schema_name>.]<table_name> SET (time_to_live_in_seconds = '<num>');
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET SCHEMA <new_schema>;Manage refresh tasks
Pause auto-refresh
Use this when you need to temporarily halt all refresh activity — for example, during maintenance or upstream data migration. After pausing, all subsequent refresh tasks stop until you explicitly resume them.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (auto_refresh_enable = false);Resume auto-refresh
Resuming a paused dynamic table restores refresh behavior based on the table's original refresh settings.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (auto_refresh_enable = true);Modify freshness
Reduce freshness to get more up-to-date data; increase it to lower compute cost when near-real-time data is not required.
Only dynamic tables created with the V3.1 syntax support this parameter.
The minimum value is 1 minute. The change takes effect immediately.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (freshness = '<num> {minutes | hours}');Modify computing resources
Switch between local instance resources (local) and Serverless resources (serverless), or change the Serverless compute size. Instance-level limits apply to the maximum Serverless specifications available. For details, see Serverless Computing.
The syntax varies by version:
V4.0.7 and later
-- Switch computing resource type.
ALTER [DYNAMIC] TABLE [IF EXISTS] [<schema>.]<table_name> SET (['local' | 'serverless' | '<warehouse_name>']);
-- Set Serverless compute size (number of cores).
ALTER DYNAMIC TABLE [IF EXISTS] [<schema>.]<table_name>
SET (auto_refresh_guc_hg_experimental_serverless_computing_required_cores = '<num>');V3.1
-- Switch computing resource type.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
SET (computing_resource = '[local|serverless]');
-- Set Serverless compute size.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
SET (refresh_guc_hg_experimental_serverless_computing_required_cores = '<num>');V3.0
-- Switch computing resource type (applies separately to incremental or full refresh).
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
SET (<incremental/full>_guc_hg_computing_resource = '[local|serverless]');
-- Set Serverless compute size.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
SET (<incremental/full>_guc_hg_experimental_serverless_computing_required_cores = '<num>');Modify the refresh mode
Change the refresh mode when your query or data pipeline requirements change — for example, switching from incremental refresh to full refresh after adding operators that incremental refresh does not support.
After changing to full refresh, the original incremental refresh task stops. Reconfigure any refresh-related properties as needed.
The system automatically cleans up the state table used for incremental refresh to reduce storage usage.
For dynamic tables with logical partitions, the change takes effect only for future partitions. For non-partitioned dynamic tables, it takes effect immediately.
Supported transitions by version:
| Transition | Supported from |
|---|---|
| Incremental refresh to full refresh | V3.0 |
| Auto-refresh to full refresh | V3.1 |
V3.1 syntax
ALTER DYNAMIC TABLE <schema_name>.<table_name> SET (auto_refresh_mode = '<full/auto>');V3.0 syntax
ALTER DYNAMIC TABLE <schema_name>.<table_name> SET (refresh_mode = 'full');Modify the active partition time range
For dynamic tables with logical partitions, narrow or expand the active partition range to control which partitions are included in auto-refreshes.
Supported in V3.1 and later only.
The change applies to future partitions only. Existing partitions are not affected.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
SET (auto_refresh_partition_active_time = '<num> {minutes | hours | days}');Modify the refresh start time (V3.0 only)
Set a future start time for auto-refresh tasks. Only dynamic tables created with the V3.0 syntax support this parameter.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
SET (<incremental/full>_auto_refresh_schd_start_time = '<timestamptz>');Modify the refresh interval (V3.0 only)
Change how frequently auto-refresh runs. Only dynamic tables created with the V3.0 syntax support this parameter.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
SET (<incremental/full>_auto_refresh_interval = '[<num> { minutes | hours}]');Modify the query definition
V3.1.18 and later
Starting from Hologres V3.1.18, you can update the query definition of a dynamic table to add columns. The new query must produce a schema compatible with the original.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
AS
<query>;Compatibility requirements
The new query must satisfy all of the following:
Both the original and new query produce the same table type: both partitioned, or both non-partitioned.
Primary keys (PKs) are identical.
Distribution keys are identical. You cannot modify the distribution key.
Partition keys are identical. You cannot modify the partition key.
Clustering key, segment key, storage mode (column store or row-column hybrid store), dictionary encoding, and bitmap index are identical.
Field names are identical. You cannot rename fields.
Fields with the same name have the same data type and NULLABLE property.
Column modification rules
Adding columns is supported. Dropping columns is not.
Existing data is unaffected. New columns are populated with NULL until the next refresh.
Refresh behavior after modifying the query definition
After the query definition is updated, the next refresh is triggered as follows:
| Table type | Next refresh behavior |
|---|---|
| Non-partitioned dynamic table | The next refresh (auto or manual) triggers a Refresh Overwrite. |
| Dynamic table with logical partitions | Active partitions trigger a Refresh Overwrite during the next auto-refresh. Historical partitions require a manual refresh. |
If the new query contains operators that incremental refresh does not support, the effective refresh mode changes based on the current setting:
Current auto_refresh_mode | New query supports incremental refresh | New query does not support incremental refresh |
|---|---|---|
auto | refresh_mode from table creation is retained. | refresh_mode automatically changes to full refresh. |
incremental | Incremental refresh is retained. | Refresh fails. Change the mode to full refresh manually. |
full | Full refresh is retained. | Full refresh is retained. |
Example: add a column
Step 1: Prepare the source table and dynamic table.
-- Create a source table.
CREATE TABLE employees (
department_id INT,
employee_name VARCHAR
);
-- Insert sample data.
INSERT INTO employees (department_id, employee_name) VALUES
(1, 'John'),
(1, 'Jane'),
(1, 'John'), -- duplicate
(2, 'Alice'),
(2, 'Bob'),
(2, 'Alice'); -- duplicate
-- Create a dynamic table that groups employees by department.
CREATE DYNAMIC TABLE dt_employees
WITH (
freshness = '1 minutes',
auto_refresh_mode = 'auto',
distribution_key = 'department_id'
)
AS
SELECT department_id
FROM employees
GROUP BY department_id;
-- Verify the initial data.
SELECT * FROM dt_employees;Step 2: Add a column by updating the query definition.
ALTER DYNAMIC TABLE dt_employees
AS
SELECT
department_id,
STRING_AGG(DISTINCT employee_name, ', ') AS unique_employees
FROM employees
GROUP BY department_id;Immediately after the statement runs, the new column contains NULL:
department_id | unique_employees
--------------+------------------
1 | \N
2 | \NAfter the next refresh completes, the column is populated:
department_id | unique_employees
--------------+------------------
1 | Jane, John
2 | Bob, AliceV3.0 syntax
Hologres V3.0 supports modifying the query definition, but only in full refresh mode. Incremental refresh mode is not supported.
Modifying the query definition changes only the query definition. It does not change the original field names or field properties.
If the fields in the new query are inconsistent with the original fields, refresh errors or data inconsistency may occur.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema>.]<table_name>
SET (task_definition = $$<new_query>$$);Use$$ ... $$instead of single quotation marks (''). If you use single quotation marks, the DDL retrieved byHG_DUMP_SCRIPTmay be inconsistent with what HoloWeb displays, because PostgreSQL treats the input as an identifier and truncates it to 128 characters.
Modify table properties
The following table properties can be modified. Properties not listed here are not supported. For other table alterations, see ALTER TABLE.
ALTER DYNAMIC TABLE RENAMEandALTER DYNAMIC TABLE SET SCHEMAare supported in V3.1.20 and later. In earlier versions, useALTER TABLE RENAMEandALTER TABLE SET SCHEMA.
-- Rename the table (ALTER DYNAMIC TABLE RENAME requires V3.1.20+).
ALTER DYNAMIC TABLE [IF EXISTS] <table_name> RENAME TO <new_name>;
-- Modify dictionary encoding.
ALTER DYNAMIC TABLE [<schema_name>.]<table_name>
SET (dictionary_encoding_columns = '[<columnName>{:[on|off|auto]}[,...]]');
-- Modify bitmap index.
ALTER DYNAMIC TABLE [<schema_name>.]<table_name>
SET (bitmap_columns = '[<columnName>{:[on|off]}[,...]]');
-- Modify the time-to-live (TTL) in seconds.
ALTER DYNAMIC TABLE [<schema_name>.]<table_name>
SET (time_to_live_in_seconds = '<num>');
-- Move the table to a different schema.
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET SCHEMA <new_schema>;