Tous les produits
Search

Ce produit

    Hologres:Alter dynamic table

    Centre de documentation

    Hologres:Alter dynamic table

    Dernière mise à jour :Aug 11, 2026

    Utilisez l'instruction ALTER DYNAMIC TABLE pour modifier le comportement d'actualisation, les ressources de calcul, la définition de la requête et les propriétés d'une table dynamique. Seules les opérations décrites dans cette rubrique sont prises en charge.

    Syntaxe

    Les instructions suivantes résument toutes les opérations ALTER DYNAMIC TABLE prises en charge. Chaque section ci-dessous détaille l'utilisation, les paramètres et les contraintes de version.

    -- Pause or resume auto-refresh
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (auto_refresh_enable = false | true);

-- Modify freshness (V3.1+ syntax only)
ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (freshness = '<num> {minutes | hours}');

-- Modify computing resource
ALTER [DYNAMIC] TABLE [IF EXISTS] [<schema>.]<table_name> SET (['local' | 'serverless' | '<warehouse_name>']); -- V4.0.7+
ALTER DYNAMIC TABLE [IF EXISTS] [<schema>.]<table_name> SET (auto_refresh_guc_hg_experimental_serverless_computing_required_cores = '<num>'); -- V4.0.7+

-- 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>;

    Gérer les tâches d'actualisation

    Suspendre l'actualisation automatique

    Suspendez l'actualisation lorsque vous devez interrompre temporairement toute activité, par exemple lors d'une maintenance ou d'une migration de données en amont. Une fois la suspension effectuée, toutes les tâches d'actualisation ultérieures s'arrêtent jusqu'à reprise explicite.

    ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (auto_refresh_enable = false);

    Reprendre l'actualisation automatique

    La reprise d'une table dynamique suspendue rétablit le comportement d'actualisation selon les paramètres d'origine de la table.

    ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (auto_refresh_enable = true);

    Modifier la fraîcheur des données

    Réduisez la valeur de fraîcheur pour obtenir des données plus récentes ; augmentez-la pour diminuer les coûts de calcul lorsque des données en temps quasi réel ne sont pas nécessaires.

    Ce paramètre est uniquement pris en charge pour les tables dynamiques créées avec la syntaxe V3.1.

    La valeur minimale est de 1 minute. La modification prend effet immédiatement.

    ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name> SET (freshness = '<num> {minutes | hours}');

    Modifier les ressources de calcul

    Basculez entre les ressources d'instance (local) et les ressources serverless (serverless), ou modifiez la taille du calcul serverless. Les limites au niveau de l'instance s'appliquent aux spécifications serverless maximales disponibles. Pour plus de détails, consultez la rubrique Utiliser le calcul serverless.

    La syntaxe varie selon la version :

    V4.0.7+

    -- Switch computing resource type.
ALTER [DYNAMIC] TABLE [IF EXISTS] [<schema>.]<table_name> SET (['local' | 'serverless' | '<warehouse_name>']);

-- Set Serverless compute size (number of vCPUs).
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.
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>');

    Modifier le mode d'actualisation

    Modifiez le mode d'actualisation lorsque les exigences de votre requête ou de votre pipeline de données évoluent, par exemple pour passer d'une actualisation incrémentielle à une actualisation complète après l'ajout d'opérateurs non pris en charge par le mode incrémentiel.

    Important

    • Après le passage à l'actualisation complète, la tâche d'actualisation incrémentielle d'origine s'arrête. Reconfigurez les propriétés liées à l'actualisation si nécessaire.

    • Hologres nettoie automatiquement la table d'état utilisée pour l'actualisation incrémentielle afin de réduire l'utilisation du stockage.

    • Pour les tables dynamiques partitionnées logiquement, la modification ne prend effet que pour les futures partitions. Pour les tables dynamiques non partitionnées, elle prend effet immédiatement.

    Transitions prises en charge par version :

    |
    **Transition**
    |
    **Prise en charge à partir de**
    | | --- | --- | |
    Actualisation incrémentielle vers actualisation complète
    |
    V3.0
    | |
    Actualisation automatique vers actualisation complète
    |
    V3.1
    |

    Syntaxe V3.1

    ALTER DYNAMIC TABLE <schema_name>.<table_name> SET (auto_refresh_mode = '<full/auto>');

    Syntaxe V3.0

    ALTER DYNAMIC TABLE <schema_name>.<table_name> SET (refresh_mode = 'full');












    Modifier la plage temporelle des partitions actives

    Pour les tables dynamiques partitionnées logiquement, réduisez ou élargissez la plage des partitions actives afin de contrôler quelles partitions sont incluses dans les actualisations automatiques.

    Pris en charge uniquement dans les versions V3.1 et ultérieures.
    La modification s'applique uniquement aux futures partitions. Les partitions existantes ne sont pas affectées.
    ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
  SET (auto_refresh_partition_active_time = '<num> {minutes | hours | days}');

    Modifier l'heure de début de l'actualisation (V3.0 uniquement)

    Définissez une heure de début future pour les tâches d'actualisation automatique. Ce paramètre est uniquement pris en charge pour les tables dynamiques créées avec la syntaxe V3.0.

    ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
  SET (<incremental/full>_auto_refresh_schd_start_time = '<timestamptz>');

    Modifier l'intervalle d'actualisation (V3.0 uniquement)

    Modifiez la fréquence d'exécution de l'actualisation automatique. Ce paramètre est uniquement pris en charge pour les tables dynamiques créées avec la syntaxe V3.0.

    ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
  SET (<incremental/full>_auto_refresh_interval = '[<num> { minutes | hours}]');

    Modifier la définition de la requête

    V3.1.18 et versions ultérieures

    À partir de Hologres V3.1.18, vous pouvez mettre à jour la définition de la requête d'une table dynamique pour ajouter des colonnes. La nouvelle requête doit produire un schéma compatible avec l'original.

    ALTER DYNAMIC TABLE [IF EXISTS] [<schema_name>.]<table_name>
AS
<query>;

    Exigences de compatibilité

    La nouvelle requête doit satisfaire à toutes les conditions suivantes :

    • Les requêtes d'origine et nouvelles produisent le même type de table : toutes deux partitionnées ou toutes deux non partitionnées.

    • Les clés primaires (PK) sont identiques.

    • Les clés de distribution sont identiques.

    • Les clés de partitionnement sont identiques.

    • La clé de clustering, la clé de segment, l'orientation de stockage (orientée colonne ou hybride ligne-colonne), l'encodage de dictionnaire et l'index bitmap sont identiques.

    • Les noms des champs sont identiques.

    • Les champs portant le même nom possèdent le même type de données et la même propriété NULLABLE.

    Règles de modification des colonnes

    • L'ajout de colonnes est pris en charge. La suppression de colonnes ne l'est pas.

    • Les données existantes ne sont pas affectées. Les nouvelles colonnes sont renseignées avec NULL jusqu'à la prochaine actualisation.

    Comportement d'actualisation après modification de la définition de la requête

    Une fois la définition de la requête mise à jour, la prochaine actualisation se déclenche comme suit :

    |
    **Type de table**
    |
    **Comportement de la prochaine actualisation**
    | | --- | --- | |
    Table dynamique non partitionnée
    |
    La prochaine actualisation (automatique ou manuelle) déclenche un écrasement des données.
    | |
    Table dynamique avec partitions logiques
    |
    Les partitions actives déclenchent un écrasement des données lors de la prochaine actualisation automatique. Les partitions historiques nécessitent une actualisation manuelle.
    |

    Si la nouvelle requête contient des opérateurs non pris en charge par l'actualisation incrémentielle, le mode d'actualisation effectif change en fonction du paramètre actuel :

    |
    **Paramètre ****auto_refresh_mode** actuel
    |
    **La nouvelle requête prend en charge l'actualisation incrémentielle**
    |
    **La nouvelle requête ne prend pas en charge l'actualisation incrémentielle**
    | | --- | --- | --- | |
    `auto`
    |
    Le paramètre `refresh_mode` défini lors de la création de la table est conservé.
    |
    Le paramètre `refresh_mode` passe automatiquement en actualisation complète.
    | |
    `incremental`
    |
    L'actualisation incrémentielle est conservée.
    |
    L'actualisation échoue. Modifiez manuellement le mode pour passer à l'actualisation complète.
    | |
    `full`
    |
    L'actualisation complète est conservée.
    |
    L'actualisation complète est conservée.
    |



































    Exemple : ajouter une colonne

    Étape 1 : Préparez la table source et la table dynamique.

    -- 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;

    Étape 2 : Ajoutez une colonne en mettant à jour la définition de la requête.

    ALTER DYNAMIC TABLE dt_employees
AS
SELECT
    department_id,
    STRING_AGG(DISTINCT employee_name, ', ') AS unique_employees
FROM employees
GROUP BY department_id;

    Immédiatement après l'exécution de l'instruction, la nouvelle colonne contient NULL :

    department_id | unique_employees
--------------+------------------
1             | \N
2             | \N

    Une fois la prochaine actualisation terminée, la colonne est renseignée :

    department_id | unique_employees
--------------+------------------
1             | Jane, John
2             | Bob, Alice

    Syntaxe V3.0

    Hologres V3.0 permet de modifier la définition de la requête, mais uniquement en mode d'actualisation complète. Le mode d'actualisation incrémentielle n'est pas pris en charge.

    La modification de la définition de la requête change uniquement cette définition. Elle ne modifie ni les noms des champs d'origine ni leurs propriétés.
    Si les champs de la nouvelle requête sont incohérents avec les champs d'origine, des erreurs d'actualisation ou des incohérences de données peuvent survenir.
    ALTER DYNAMIC TABLE [IF EXISTS] [<schema>.]<table_name>
  SET (task_definition = $$<new_query>$$);
    Utilisez $$ ... $$ au lieu des guillemets simples ( '' ). Si vous utilisez des guillemets simples, le script DDL récupéré par HG_DUMP_SCRIPT peut être incohérent avec l'affichage de HoloWeb, car PostgreSQL traite l'entrée comme un identifiant et la tronque à 128 caractères.

    Modifier les propriétés de la table

    Les propriétés de table suivantes peuvent être modifiées. Les propriétés non répertoriées ici ne sont pas prises en charge. Pour les autres modifications de table, consultez la rubrique ALTER TABLE.

    Les instructions ALTER DYNAMIC TABLE RENAME et ALTER DYNAMIC TABLE SET SCHEMA sont prises en charge à partir de la version V3.1.20. Dans les versions antérieures, utilisez ALTER TABLE RENAME et ALTER TABLE SET SCHEMA .
    -- Rename the table (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>;