Hologres:Default behavior changes

V4.2

V4.1

SET password_encryption = 'md5';
ALTER USER "BASIC$user" WITH PASSWORD 'password';

V4.0 (septembre 2025)

V3.2 (août 2026)

• Modification du nombre par défaut de threads de service RPC pour les requêtes de tables externes MaxCompute

  Modification : À partir de Hologres V3.2.42, la valeur par défaut du paramètre de thread de service RPC holo_seahawks_rpc_service_thread_number passe de 300 à 150.

  Impact : Les requêtes de tables externes MaxCompute exécutées sur le moteur SQE avec un QPS élevé connaissent une augmentation modérée de la latence. En contrepartie, l'instance fonctionne de manière plus stable : les requêtes de tables externes n'entrent plus en concurrence avec les ressources des requêtes de tables internes ni ne dégradent leurs performances, ce qui améliore la santé globale de l'instance.

  Recommandation : Mettez à niveau l'instance vers Hologres V4.1 ou une version ultérieure. À partir de cette version, les requêtes de tables externes s'exécutent sur un nouveau moteur offrant de meilleures performances de requête tout en maintenant la stabilité.

• Nouvelle limite sur le nombre de fichiers lus depuis une seule table externe MaxCompute

  Modification : À partir de Hologres V3.2.43, un nouveau paramètre GUC, hg_experimental_maxcompute_sdk_split_total_file_count_limit, a été ajouté avec une valeur par défaut de 100 000. Si une seule table externe MaxCompute lit plus de fichiers que cette limite au cours d'une requête, celle-ci échoue avec une erreur. Avant cette modification, ce paramètre n'existait pas et le nombre de fichiers lus depuis une seule table était illimité.

  Impact : Charges de travail interrogeant des tables externes MaxCompute, en particulier celles contenant un grand nombre de petits fichiers. Les requêtes dépassant la limite sont bloquées, ce qui empêche une utilisation excessive de la mémoire de déclencher une erreur OOM (Out Of Memory) et d'affecter les autres charges de travail sur l'instance.

  Recommandation : Fusionnez d'abord les petits fichiers côté MaxCompute pour réduire le nombre de fichiers lus par chaque requête. Si la fusion des petits fichiers n'est pas envisageable pour le moment, vous pouvez augmenter la valeur de hg_experimental_maxcompute_sdk_split_total_file_count_limit après avoir évalué les ressources restantes de l'instance. Une valeur plus élevée augmente le seuil d'utilisation de la mémoire de l'instance. Définissez ce paramètre de manière conservatrice en fonction de votre charge de travail réelle et continuez de surveiller l'utilisation de la mémoire après l'ajustement.

V3.2 (juillet 2025)

• Ajout de mots clés non réservés tels que Branch, Overwrite, Parameter et Tag ; ajout de mots clés réservés tels que Lambda et Qualify. Pour plus d'informations sur les mots clés, reportez-vous à la documentation Mots clés PostregSQL.

• À partir de Hologres V3.2, l'optimisation adaptative des CTE (Common Table Expressions) est prise en charge. La stratégie de matérialisation des CTE est déterminée par deux paramètres GUC : optimizer_cte_inlining et hg_cte_strategy. Ces paramètres sont indépendants et peuvent être configurés séparément, quel que soit l'ordre de définition. Les comportements sont les suivants :

  • Lorsque optimizer_cte_inlining = off, les CTE sont réutilisées, quelle que soit la valeur du paramètre hg_cte_strategy.

  • Lorsque optimizer_cte_inlining = on, les CTE ne sont plus systématiquement intégrées (inlined). La politique appliquée aux CTE est déterminée par le paramètre hg_cte_strategy :

    • Si hg_cte_strategy = auto (valeur par défaut), l'optimiseur de requêtes (QO) sélectionne automatiquement s'il faut intégrer ou réutiliser la CTE en fonction de facteurs tels que sa complexité.

    • Lorsque hg_cte_strategy = inlining, les CTE sont systématiquement intégrées.

    • Lorsque hg_cte_strategy = reuse, les CTE sont systématiquement réutilisées.

• À partir de Hologres V3.2, la fonctionnalité Fast Rows est activée par défaut. Lorsqu'une table ne dispose pas de statistiques, l'optimiseur récupère automatiquement le nombre réel de lignes pour générer un plan d'exécution plus efficace.

  Ce comportement est automatique lors de la mise à niveau et ne nécessite aucune configuration. Pour plus de détails, reportez-vous à la rubrique ANALYZE et AUTO ANALYZE.

V3.1 (août 2026)

• Modification du nombre par défaut de threads de service RPC pour les requêtes sur les tables externes MaxCompute

  Changement : À partir de Hologres V3.1.53, la valeur par défaut du paramètre de thread de service RPC holo_seahawks_rpc_service_thread_number passe de 300 à 150.

  Impact : Les requêtes sur les tables externes MaxCompute exécutées sur le moteur SQE avec un QPS élevé connaissent une augmentation modérée de la latence. En contrepartie, l'instance fonctionne de manière plus stable : les requêtes sur les tables externes n'entrent plus en concurrence avec les ressources des requêtes sur les tables internes ni ne dégradent leurs performances, ce qui améliore la santé globale de l'instance.

  Recommandation : Mettez à niveau l'instance vers Hologres V4.1 ou une version ultérieure. À partir de cette version, les requêtes sur les tables externes s'exécutent sur un nouveau moteur qui offre de meilleures performances tout en maintenant la stabilité.

• Nouvelle limite sur le nombre de fichiers lus à partir d'une seule table externe MaxCompute

  Changement : À partir de Hologres V3.1.53, un nouveau paramètre GUC hg_experimental_maxcompute_sdk_split_total_file_count_limit est ajouté, avec une valeur par défaut de 100 000. Si une seule table externe MaxCompute lit plus de fichiers que cette limite au cours d'une requête, celle-ci échoue avec une erreur. Avant cette modification, le paramètre n'existait pas et le nombre de fichiers lus à partir d'une seule table était illimité.

  Impact : Charges de travail interrogeant des tables externes MaxCompute, en particulier celles contenant un grand nombre de petits fichiers. Les requêtes dépassant la limite sont bloquées, ce qui empêche une utilisation excessive de la mémoire de déclencher une erreur OOM (Out Of Memory) et d'affecter les autres charges de travail sur l'instance.

  Recommandation : Fusionnez d'abord les petits fichiers côté MaxCompute pour réduire le nombre de fichiers lus par chaque requête. Si la fusion des petits fichiers n'est pas faisable pour le moment, vous pouvez augmenter la valeur du paramètre hg_experimental_maxcompute_sdk_split_total_file_count_limit après avoir évalué les ressources restantes de l'instance. Une valeur plus élevée augmente le seuil d'utilisation de la mémoire de l'instance. Définissez-la de manière conservative en fonction de votre charge de travail réelle et surveillez l'utilisation de la mémoire après l'ajustement.

V3.1 (mai 2025)

• Tables dynamiques :

  • Syntaxe

    À partir de Hologres V3.1, les tables dynamiques utilisent une nouvelle syntaxe plus concise. Après la mise à niveau des tables dynamiques créées dans la version V3.0 vers la V3.1, seules les opérations ALTER peuvent être effectuées sur une table utilisant l'actualisation complète des données. Pour créer une nouvelle table, vous devez utiliser la nouvelle syntaxe de la version V3.1. Pour une table utilisant l'actualisation incrémentielle des données, vous devez recréer la table en utilisant la nouvelle syntaxe. Pour plus d'informations, reportez-vous à la rubrique Créer une table dynamique.

  • Utilisation des ressources

    • Ressources d'actualisation

      Les tables dynamiques créées dans Hologres V3.1 utilisent par défaut des ressources de calcul serverless pour exécuter les tâches. Si l'instance actuelle n'a pas le calcul Serverless activé, elle revient automatiquement aux ressources de l'instance. Les tables créées dans Hologres V3.0 continuent d'utiliser les ressources spécifiées lors de la création de la table. Pour plus d'informations, reportez-vous à la rubrique Créer une table dynamique.

    • Création de tables utilisant les ressources de l'instance

      • Nouvelle syntaxe (Hologres V3.1 et V3.2) : Les entrepôts virtuels principaux des groupes de tables de base et des tables dynamiques sont utilisés.

      • Ancienne syntaxe (Hologres V3.0) et nouvelle syntaxe (Hologres V4.1) : L'entrepôt virtuel principal du groupe de tables de la table dynamique est utilisé.

  • Nombre de connexions

    La nouvelle syntaxe maintient une connexion supplémentaire par table dynamique. Si votre instance présente une utilisation élevée des connexions et des centaines de tables dynamiques, supprimez les connexions inactives pour éviter tout problème.

  • Méthodes de lecture des données incrémentielles à partir de la table de base

    À partir de Hologres V3.1 et versions ultérieures, la méthode stream est utilisée pour identifier les modifications de données dans la table de base. Par rapport à la journalisation binaire, la méthode stream offre de meilleures performances et est plus rentable. Après la mise à niveau de votre instance vers la version V3.1, la méthode stream est utilisée par défaut. Si la journalisation binaire est activée pour votre table dans la version V3.0, désactivez-la rapidement pour éviter des coûts de stockage supplémentaires. Pour plus d'informations, reportez-vous à la rubrique Tables dynamiques.

• La fonctionnalité de file d'attente des requêtes a terminé sa phase Beta et est disponible pour une utilisation en production. Pour plus d'informations, reportez-vous à la rubrique File d'attente des requêtes.

• TRUNCATE est désormais une instruction DML (au lieu de DDL), ce qui réduit la pression sur les nœuds FE. Pour revenir au comportement DDL, désactivez le paramètre GUC hg_enable_truncate_as_dml. Toutefois, lors de l'exécution d'une opération TRUNCATE sur une table avec la journalisation binaire activée, vous devez désactiver la journalisation binaire au niveau de la session. Pour plus d'informations, reportez-vous à la rubrique TRUNCATE.

• Lorsque vous importez des données dans une table avec une clé primaire en utilisant COPY, le paramètre GUC hg_experimental_copy_enable_on_conflict est activé par défaut. Cela vous permet de définir des politiques de mise à jour des données lors de l'importation dans des tables avec des clés primaires. Pour plus d'informations, reportez-vous à la rubrique COPY.

• Lorsque vous utilisez la fonctionnalité hg_insert_overwrite, le nombre de colonnes et leurs types de données spécifiés dans l'instruction SQL (instruction SELECT standard) doivent correspondre strictement à ceux de la table cible (table interne Hologres). Sinon, le message d'erreur error: table "hg_alias" has x columns available but x columns specified ou error: column xx is of type xxx but expression is of type xxx s'affiche. Pour plus d'informations, reportez-vous à la rubrique INSERT OVERWRITE.

• La table système hg_table_storage_status est mise à jour. À partir de Hologres V3.1, la table système n'inclut plus les données de table stockées en mémoire (table en mémoire). Elle reflète uniquement le stockage physique réel des tables. Pour plus d'informations sur le mécanisme des tables en mémoire, reportez-vous à la rubrique INSERT.

• Ajout de mots clés non réservés : async, logical, purge, recover, rebuild, resume et suspend. Reportez-vous à la documentation Mots clés PostgreSQL.

V3.0

WHERE (pk1 = 1 AND pk2 = 1) OR (pk1 = 2 AND pk2 = 2) OR (pk1 = 3 AND pk2 = 3)-- The number of combinations in this example is 3.
    
WHERE pk1 IN (1, 2, 3) AND pk2 IN (1,2,3)-- The number of combinations in this example is 9. Formula: 3 × 3 = 9.

V2.2

V2.2 (juillet 2024)

Lorsque JDBC (Java Database Connectivity) est utilisé pour consommer les journaux binaires Hologres, le nombre maximal de walsenders disponibles pour un worker passe de 1 000 à 600. Le nombre de walsenders est calculé en fonction du nombre de slots. Pour plus d'informations, reportez-vous à la rubrique Consommer Binlog via JDBC. Nous vous recommandons d'utiliser le mode jdbc_fixed pour consommer les journaux binaires Hologres. Contrairement à la consommation de journaux en mode JDBC, la consommation en mode jdbc_fixed n'occupe pas de connexions et n'est pas soumise aux limites du nombre de walsenders. Pour plus d'informations sur le mode jdbc_fixed, reportez-vous à la rubrique Connecteur SQL Hologres.

V2.2 (juin 2024)

Dans Hologres V2.2 et versions ultérieures, la capacité sous-jacente de collecte des journaux de requêtes lentes est automatiquement mise à niveau pour permettre à Hologres d'enregistrer plus d'informations sur les requêtes lentes. Cela permet au personnel métier d'effectuer une gestion fine basée sur l'état des requêtes exécutées sur les instances Hologres. Pour plus d'informations sur les journaux de requêtes lentes, reportez-vous à la rubrique Obtenir et analyser les journaux de requêtes lentes. La collecte des journaux de requêtes lentes est améliorée sur les aspects suivants :

• Les requêtes qui échouent pour des raisons telles qu'une syntaxe invalide, des échecs d'analyse du plan et des autorisations insuffisantes sont enregistrées. Ces requêtes n'étaient pas enregistrées dans les versions antérieures à Hologres V2.2. Nous vous recommandons d'utiliser la fonctionnalité Diagnostics SQL pour gérer les requêtes ayant échoué.

• Si une transaction contient plusieurs instructions DDL (Data Definition Language), telles que BEGIN; DROP TABLE xxx; COMMIT;, l'ensemble de la transaction est enregistré comme un seul enregistrement de requête dans les journaux de requêtes lentes. Cependant, la métrique Query QPS compte la transaction comme plusieurs instructions DDL. Exemple :

  -- Initiate a query that contains multiple DDL statements in a transaction.
  BEGIN;
  DROP TABLE xxx;-- The execution succeeds.
  CREATE TABLE xxx -- The execution fails.
  ROLLBACK;

  • Le code suivant montre le résultat dans les journaux de requêtes lentes :

    query_id | status  | Query
    ---------|---------|------------
    xxxx     |  FAILED |begin;drop table ;create table;rollback;

  • Le code suivant montre le résultat dans le système de surveillance :

    Query QPS: 4 records
    Failed Query QPS: 1 record

V2.2 (mai 2024)

• Dans Hologres V2.2 et versions ultérieures, les propriétés de table renvoyées par hg_dump_script sont affichées avec la syntaxe WITH au lieu de la syntaxe CALL. Cela permet d'améliorer la commodité et la lisibilité de l'instruction CREATE TABLE. Pour plus d'informations, reportez-vous à la section « Interroger un schéma de table » de la rubrique Vue d'ensemble.

• Dans Hologres V2.2.7 et versions ultérieures, la valeur par défaut passe de 1 seconde à 100 millisecondes. Après cette modification, les journaux de requêtes lentes enregistrent les instructions SQL qui prennent plus de 100 millisecondes au lieu de 1 seconde. Les instructions SQL incluent les instructions INSERT, SELECT, UPDATE et DELETE. Pour plus d'informations, reportez-vous à la rubrique Obtenir et analyser les journaux de requêtes lentes.

• Dans Hologres V2.2.9 et versions ultérieures, les résultats renvoyés par les requêtes ponctuelles de paires clé-valeur à l'aide de plans fixes ne sont pas triés selon la clé primaire de la clause WHERE.

  Exemple de requêtes ponctuelles à l'aide de plans fixes

  CREATE TABLE test_t (id INT PRIMARY key, col INT);
  INSERT INTO test_t VALUES (1,1),(2,2),(3,3);
  
  -- In versions earlier than Hologres V2.2.9, the returned results are ordered based on the primary key (id) in the WHERE clause. 
  SELECT * FROM test_t WHERE id IN (1,2,3);
  id | col 
  ----+----- 
  1 | 1 
  2 | 2 
  3 | 3
  
  -- In Hologres V2.2.9 and later, the returned results are not ordered based on the primary key (id) in the WHERE clause. Data in the result returned by each query may also be displayed in a different order. 
  SELECT * FROM test_t WHERE id IN (1,2,3);
  id | col 
  ----+----- 
  3 | 3 
  1 | 1 
  2 | 2

V2.2 (avril 2024)

• Dans Hologres V2.2 et versions ultérieures, Hologres utilise par défaut un rôle lié au service pour accéder aux tables externes MaxCompute. Lors de l'achat ou de la mise à niveau vers V2.2 ou une version ultérieure, créez le rôle lié au service et accordez-lui les autorisations requises. Les rôles liés au service permettent un accès inter-services autorisé et préviennent les risques liés aux erreurs de manipulation. Pour plus d'informations, reportez-vous à la rubrique Rôle lié au service pour Hologres.

• Dans Hologres V2.2 et versions ultérieures, la stratégie d'optimiseur par défaut passe de exhaustive à exhaustive2, améliorant les performances de 20 % à 40 % dans la plupart des cas. Pour les requêtes left outer join, le plan peut être sous-optimal avec une utilisation mémoire plus élevée. Pour revenir en arrière, exécutez set optimizer_join_order = 'exhaustive'; pour revenir à exhaustive .

• Dans Hologres V2.2 et versions ultérieures, la valeur du type de moteur pour les processus utilisant des plans fixes passe de SDK à FixedQE dans les journaux de requêtes lentes. Cela garantit la cohérence des noms dans les journaux de requêtes lentes et les métriques.

• Dans Hologres V2.2 et versions ultérieures, le nombre de connexions à un nœud FE passe de 128 à 256. Le nombre total de connexions est doublé. Pour plus d'informations, reportez-vous à la rubrique Gestion des instances.

• Les fonctionnalités INSERT OVERWRITE et Fonctions BSI sont désormais généralement disponibles.

• Dans Hologres V2.2 et versions ultérieures, l'instruction SELECT hg_dump_script() renvoie les propriétés de création de table avec la syntaxe WITH au lieu de la syntaxe CALL. Cette modification améliore la commodité et la lisibilité de la création de table. Pour plus d'informations, reportez-vous à la rubrique Afficher un schéma de table.

V2.1 (juin 2024)

À partir de Hologres V2.1.27, si vous utilisez Realtime Compute for Apache Flink avec VVR 8.0.7 ou une version ultérieure pour consommer les journaux binaires de Hologres, le mode JDBC est automatiquement mis à niveau vers le mode jdbc_fixed. Contrairement aux requêtes en mode JDBC, celles en mode jdbc_fixed ne consomment pas de connexions et leurs performances ne sont pas limitées par le nombre maximal de walsenders. Pour plus d'informations sur le mode jdbc_fixed, consultez la rubrique Connecteur SQL Hologres. Pour en savoir plus sur le mode JDBC, reportez-vous à la section Consommer des journaux binaires via JDBC.

V2.1 (mars 2024)

Lorsque vous utilisez Realtime Compute for Apache Flink pour consommer les journaux binaires de Hologres, le mode HoloHub n'est plus pris en charge et la configuration 'sdkMode'='holohub' devient invalide. Seul le mode Java Database Connectivity (JDBC) est désormais supporté. Le mode JDBC offre une stabilité supérieure au mode HoloHub et prend en charge un plus grand nombre de types de données. Avant de mettre à niveau votre instance Hologres vers la version V2.1, appliquez l'une des solutions suivantes pour vérifier le déploiement Realtime Compute for Apache Flink et votre instance Hologres, afin de garantir le bon fonctionnement du déploiement. Pour plus de détails, consultez la rubrique Consommer des journaux binaires via JDBC.

• Solution 1 : recommandée. Mettez à niveau la version VVR de Realtime Compute for Apache Flink vers la version 8.0.7 ou ultérieure, puis effectuez la mise à niveau de votre instance Hologres. Dans ce cas, Realtime Compute for Apache Flink bascule automatiquement du mode HoloHub vers le mode JDBC.

• Solution 2 : mettez à niveau la version VVR de Realtime Compute for Apache Flink vers une version comprise entre 6.0.7 et 8.0.5, ajoutez la configuration 'sdkMode'='jdbc' à la table source de Realtime Compute for Apache Flink, puis redémarrez le déploiement. Accordez l'un des ensembles d'autorisations suivants au compte utilisateur utilisé pour se connecter à l'instance Hologres. Une fois que vous avez confirmé le bon fonctionnement du déploiement, mettez à niveau votre instance Hologres.

  • Autorisations Superuser sur l'instance Hologres

  • Les autorisations du propriétaire de la table, l'autorisation CREATE DATABASE et les autorisations du rôle de réplication de l'instance Hologres

• Solution 3 : non recommandée. Mettez à niveau la version VVR de Realtime Compute for Apache Flink vers la version 8.0.6, puis effectuez la mise à niveau de votre instance Hologres. Dans ce scénario, Realtime Compute for Apache Flink passe automatiquement du mode HoloHub au mode JDBC. Notez que Realtime Compute for Apache Flink utilisant VVR 8.0.6 présente un défaut connu : si les tables de dimension contiennent un nombre excessif de champs, le déploiement des brouillons Realtime Compute for Apache Flink échoue en raison d'un délai d'attente dépassé. Pour plus d'informations, consultez la section « Notes de version du connecteur Hologres » dans la rubrique Présentation.

• Facultatif. Si vous disposez d'un grand nombre de déploiements Realtime Compute for Apache Flink basés sur VVR, vous pouvez obtenir des informations sur les déploiements et les tables en suivant les instructions de la rubrique Utiliser Realtime Compute for Apache Flink ou Blink pour consommer les journaux binaires Hologres en temps réel.

V2.1 (février 2024)

Dans Hologres V2.1.19, les opérations de multiplication et de division sur les données de type DECIMAL ont été corrigées. Dans les versions antérieures à V2.1.19, un maximum de 18 décimales était pris en charge pour les opérations de base sur les données DECIMAL. Si le résultat du calcul comportait plus de 18 décimales après une multiplication ou une division, les données étaient tronquées avant le calcul, ce qui entraînait un résultat invalide.

Par exemple, lors d'une multiplication entre deux valeurs décimales, le nombre total de chiffres avant et après la virgule (precision_ans) ainsi que le nombre de décimales (scale_ans) du résultat sont calculés selon les formules suivantes :

precision_ans = precision_l + precision_r
scale_ans  = scale_l + scale_r

Si la valeur de scale_ans dépasse 18, seules 18 décimales sont conservées. Les valeurs décimales utilisées pour la multiplication sont tronquées selon le nombre de décimales spécifié, conformément aux règles suivantes :

• Si scale_l ≤ 9, la valeur décimale concernée n'est pas tronquée et le nombre de décimales pour cette valeur dans l'opération de multiplication correspond à scale_l.

• Si scale_l > 9, la valeur décimale concernée est tronquée au nombre de décimales renvoyé par max(9,18-scale_r).

• Si scale_r ≤ 9, la valeur décimale concernée n'est pas tronquée et le nombre de décimales pour cette valeur dans l'opération de multiplication correspond à scale_r.

• Si scale_r > 9, la valeur décimale concernée est tronquée au nombre de décimales renvoyé par max(9,18-scale_l).

L'exemple de code suivant illustre ce comportement :

CREATE TABLE t (a DECIMAL(30,10), b DECIMAL(30,10));
INSERT INTO t VALUES (1.1111111111, 1.0000000000),(1.1111111112, 1.0000000000);
SELECT a, b , a*b FROM t;

• Dans les versions antérieures à V2.1.19, si un multiplicateur possède plus de 9 décimales significatives, il est tronqué au nombre de décimales spécifié, ce qui affecte négativement la précision. Par conséquent, le résultat du calcul est invalide.

  -- The calculation result in Hologres is invalid.
  1.1111111111, 1.0000000000,1.111111111000000000
  1.1111111112, 1.0000000000,1.111111111000000000
  
  -- The calculation result in PostgreSQL is valid.
  1.1111111111, 1.0000000000,1.111111111100000000
  1.1111111112, 1.0000000000,1.111111111200000000

• À partir de Hologres V2.1.19, ce problème est résolu. L'opération de multiplication est effectuée sur les valeurs décimales d'origine, puis le résultat est tronqué au nombre de décimales spécifié. Cela garantit une grande précision du résultat.

  -- The calculation result is valid.
  1.1111111111, 1.0000000000,1.111111111100000000
  1.1111111112, 1.0000000000,1.111111111200000000

V2.1 (octobre 2023)

Certaines fonctionnalités ont été optimisées.

• À partir de Hologres V2.1.12, si vous utilisez la fonctionnalité de plan fixe pour écrire des données dans une colonne de type DECIMAL sans spécifier la précision, et que la précision des données source est supérieure à celle de la colonne de destination, Hologres arrondit les données source en fonction de la précision de la colonne de destination. Dans Hologres V2.1.11 et versions antérieures, Hologres tronquait les données source selon la précision de la colonne de destination. Les instructions suivantes fournissent des exemples.

  Remarque

  À partir de Hologres V2.1.12, le processus reste identique, que la fonctionnalité de plan fixe soit utilisée ou non.

  CREATE TABLE fixed_plan_decimal (col DECIMAL(3,2));
  
  -- In Hologres V2.1.12 and later, the data 2.56 is written. In versions earlier than V2.1.12, the data 2.55 is written.
  INSERT INTO fixed_plan_decimal VALUES (2.555);
  
  -- In all Hologres versions, the data 2.55 is written.
  INSERT INTO fixed_plan_decimal VALUES (2.554);

• Les fonctionnalités Carte des données, linéage des données et Chiffrement de la transmission ont terminé leur phase bêta et sont désormais généralement disponibles.

• Les exigences en matière d'autorisations pour la consommation des journaux binaires Hologres ont été mises à jour : seule l'autorisation de lecture sur la table cible est désormais requise. Pour plus d'informations, consultez la rubrique Consommer des journaux binaires via JDBC.

• Si vous utilisez Bulkload pour importer des données dans une table interne Hologres dépourvue de clé de distribution, les performances d'importation peuvent se dégrader.

• À partir de Hologres V2.1, la syntaxe CREATE TABLE WITH PROPERTY est prise en charge afin de simplifier la configuration des propriétés de table. Pour plus de détails, reportez-vous à la rubrique CREATE TABLE.

• À partir de Hologres V2.1, la politique de compactage pour les opérations DELETE et UPDATE a été modifiée afin de récupérer rapidement les fichiers marqués. Cette modification peut réduire l'utilisation du stockage et améliorer les performances des requêtes pour les tables orientées colonnes soumises à des opérations DELETE/UPDATE fréquentes. Après la mise à niveau vers V2.1, le compactage en arrière-plan des petits fichiers historiques consomme une quantité importante de CPU et peut prendre plus de 10 minutes, voire plusieurs heures, selon le volume de fichiers.

• À partir de Hologres V2.1, un mécanisme de vérification a été ajouté pour s'assurer que toutes les colonnes spécifiées dans CONFLICT au sein de la syntaxe INSERT INTO <table_name> ON CONFLICT(<col_name>,...) DO sont bien des colonnes de clé primaire. Si l'une des colonnes n'est pas une colonne de clé primaire, l'exécution de l'instruction SQL échoue. Pour plus d'informations, consultez la rubrique INSERT ON CONFLICT (UPSERT).

• À partir de Hologres V2.1, l'extension dlf_fdw est créée par défaut pour vous permettre d'accéder aux lacs de données via des tables externes. Il n'est plus nécessaire de créer manuellement l'extension dlf_fdw. Le paramètre dlf_region n'a plus besoin d'être spécifié lors de la création d'un serveur externe. Seuls les paramètres dlf_endpoint, oss_endpoint et dlf_catalog doivent être indiqués. Une vérification du format a été ajoutée pour les paramètres dlf_endpoint et oss_endpoint afin de prévenir les erreurs. Exigences de format :

  • dlf_endpoint : dlf-share.<nation>-<region>.aliyuncs.com

  • oss_endpoint :

    • Bucket OSS : oss-<nation>-<region>-internal.aliyuncs.com

    • Bucket OSS-HDFS : oss-<nation>-<region>.oss-dls.aliyuncs.com

• Les mots-clés suivants sont désormais utilisés comme mots-clés non réservés : system_time, proctime et dynamic. Vous ne pouvez pas utiliser ces mots-clés non réservés comme noms de colonnes dans les instructions SQL ; ils ne peuvent servir que d'alias. Les mots-clés non réservés doivent être placés après AS. Exemples d'instructions :

  -- In Hologres V2.0 and earlier, the three keywords can be used as column names or aliases in SQL statements.
  SELECT xxxx SYSTEM_TIME FROM t;
  
  SELECT xxxx AS SYSTEM_TIME FROM t;
  
  -- In Hologres V2.1 and later, the three keywords can only be used as aliases in SQL statements.
  SELECT xxxx AS SYSTEM_TIME FROM t;

V2.0 (juin 2023)

Certaines fonctionnalités ont été optimisées.

• Lorsque vous utilisez Realtime Compute for Apache Flink pour consommer les journaux binaires de Hologres, le mode JDBC est pris en charge. Le mode HoloHub, spécifié par la configuration 'sdkMode'='holohub', sera progressivement abandonné. Le mode JDBC offre une stabilité supérieure au mode HoloHub et prend en charge davantage de types de données. Avant de mettre à niveau votre instance Hologres vers la version V2.0, appliquez l'une des solutions suivantes pour vérifier le déploiement Realtime Compute for Apache Flink et votre instance Hologres, afin de garantir le bon fonctionnement du déploiement. Pour plus de détails, consultez la rubrique Consommer des journaux binaires via JDBC.

  • Solution 1 : recommandée. Mettez à niveau la version VVR de Realtime Compute for Apache Flink vers la version 8.0.6 ou ultérieure, puis effectuez la mise à niveau de votre instance Hologres. Dans ce cas, Realtime Compute for Apache Flink bascule automatiquement du mode HoloHub vers le mode JDBC. Notez que Realtime Compute for Apache Flink utilisant VVR 8.0.6 présente un défaut connu : si les tables de dimension contiennent un nombre excessif de champs, le déploiement des brouillons Realtime Compute for Apache Flink échoue en raison d'un délai d'attente dépassé. Pour plus d'informations, consultez la section « Notes de version du connecteur Hologres » dans la rubrique Présentation. Nous vous recommandons de mettre à niveau la version VVR de Realtime Compute for Apache Flink vers la version 8.0.7.

  • Solution 2 : mettez à niveau la version VVR de Realtime Compute for Apache Flink vers la version 8.0.4 ou 8.0.5, puis redémarrez le déploiement. Accordez l'un des ensembles d'autorisations suivants au compte utilisateur utilisé pour se connecter à l'instance Hologres. Une fois que vous avez confirmé le bon fonctionnement du déploiement, mettez à niveau votre instance Hologres.

    • Autorisations Superuser sur l'instance Hologres

    • Les autorisations du propriétaire de la table, l'autorisation CREATE DATABASE et les autorisations du rôle de réplication de l'instance Hologres

  • Solution 3 : mettez à niveau la version VVR de Realtime Compute for Apache Flink vers une version comprise entre 6.0.7 et 8.0.3, puis effectuez la mise à niveau de votre instance Hologres. Dans ce scénario, Realtime Compute for Apache Flink continue d'utiliser le mode HoloHub pour consommer les journaux binaires de Hologres.

• Le mode d'appel de procédure distante (RPC), spécifié par la configuration 'sdkMode'='rpc' ou 'rpcMode'='true', n'est plus pris en charge par les tables de dimension et les tables de résultats de Realtime Compute for Apache Flink. Le mode JDBC est utilisé à la place. Avant de mettre à niveau votre instance Hologres vers la version V2.0, effectuez les opérations suivantes pour vérifier le déploiement Realtime Compute for Apache Flink et votre instance Hologres, afin de garantir le bon fonctionnement du déploiement. Pour plus de détails, consultez la rubrique Connecteur SQL Hologres.

  • Si la version VVR de Realtime Compute for Apache Flink est 6.0.7 ou ultérieure, le système bascule automatiquement du mode RPC vers le mode JDBC. Aucune action n'est requise.

  • Si la version VVR de Realtime Compute for Apache Flink est comprise entre 6.0.3 et 6.0.6, modifiez la configuration 'sdkMode'='rpc' en 'sdkMode'='jdbc' ou changez la configuration 'rpcMode'='true' en 'rpcMode'='false' pour les déploiements Realtime Compute for Apache Flink.

  • Si la version VVR de Realtime Compute for Apache Flink est 6.0.2 ou antérieure, modifiez la configuration 'rpcMode'='true' en 'rpcMode'='false' pour les déploiements Realtime Compute for Apache Flink.

  • Si les connexions à votre instance Hologres sont insuffisantes, nous vous recommandons de configurer le paramètre connectionPoolName afin de partager les connexions dans le pool. Vous pouvez également mettre à niveau la version VVR de Realtime Compute for Apache Flink vers la version 6.0.7 ou ultérieure et utiliser la configuration 'sdkMode'='jdbc_fixed'. Dans ce cas, aucune connexion n'est occupée.

  • Le mode RPC ne déduplique pas les données ayant la même clé primaire au sein d'un même lot. Le mode JDBC effectue automatiquement cette déduplication. Si vous devez conserver l'intégralité des données dans vos scénarios métier, utilisez la configuration 'jdbcWriteBatchSize'='1' pour empêcher la déduplication.

• À partir de Hologres V2.0, vous ne pouvez plus utiliser Blink pour effectuer des requêtes ponctuelles en temps réel sur les données de Hologres ni pour y écrire des données. Nous vous recommandons de migrer vos déploiements Blink vers Realtime Compute for Apache Flink avant de mettre à niveau votre instance Hologres.

V2.0 (avril 2023)

Certaines fonctionnalités ont été optimisées.

• À partir de Hologres V2.0, les données au format segment ne peuvent plus être stockées en mode de stockage orienté colonnes. Les instances Hologres contenant des données au format segment ne peuvent pas être mises à niveau vers V2.0 ou une version ultérieure. Vous pouvez utiliser la fonction hg_convert_segment_orc pour convertir simultanément plusieurs tables au format segment en tables au format Optimized Row Columnar (ORC). Pour plus d'informations, consultez la rubrique Mettre à niveau le format de stockage d'une table orientée colonnes.

• Une limite supérieure est imposée au nombre de shards pour un groupe de tables ou une instance. Cette mesure permet d'éviter le gaspillage de ressources dû à une mauvaise utilisation des groupes de tables. Pour plus de détails, reportez-vous à la rubrique Gérer les groupes de tables et les shards.

• L'écriture des données dans DataHub s'effectue désormais en mode JDBC plutôt qu'en mode SDK. Le mode JDBC offre une stabilité supérieure au mode SDK et prend en charge un plus grand nombre de types de données.

• Par défaut, l'extension de journal binaire est configurée. Lorsque vous consommez des données de journal binaire en mode JDBC, il n'est plus nécessaire de créer l'extension de journal binaire. De plus, le nombre maximal de walsenders utilisables est multiplié par 10. Pour une instance configurée avec 32 cœurs CPU, le nombre maximal de walsenders passe de 200 à 2 000. Les walsenders sont comptabilisés comme des slots. Pour plus d'informations, consultez la rubrique Consommer des journaux binaires via JDBC.

• Après la mise à niveau de votre instance Hologres, la fonctionnalité auto-analyze est exécutée sur les tables pour lesquelles aucune information statistique n'a été collectée. Ce processus consomme des ressources CPU et peut prendre plusieurs minutes, voire plusieurs heures, selon le nombre de tables concernées.

• La préversion publique des fonctionnalités de sauvegarde et de restauration, ainsi que celle du stockage hiérarchisé, est terminée ; ces fonctionnalités sont désormais utilisables en environnement de production.

• La préversion publique de la fonctionnalité de réplication au niveau des shards est achevée et celle-ci peut être utilisée en environnement de production. Pour plus d'informations, consultez la rubrique Réplication au niveau des shards pour un débit élevé.

• Les paramètres définissant les propriétés de table ont été standardisés. La syntaxe utilisée pour configurer les propriétés de table lorsque les noms de colonnes contiennent des lettres majuscules a changé. Pour plus de détails, reportez-vous à la rubrique CREATE TABLE. La valeur auto n'est plus prise en charge pour la propriété bitmap_columns. Cette modification n'affecte pas l'utilisation des tables existantes.

• La fonction HG_CREATE_TABLE_LIKE peut désormais hériter des index créés, des colonnes de type de données SERIAL et des colonnes pour lesquelles des index vectoriels proxima ont été créés.

V1.3 (juin 2023)

• À partir de Hologres V1.3.53, le nombre de réplicas doit être inférieur ou égal au nombre de workers. Pour plus d'informations, consultez la rubrique Réplication au niveau des shards pour un débit élevé (bêta).

• Le résultat de calcul de la fonction Avg a été optimisé. Dans les versions de Hologres antérieures à V1.3, la fonction Avg renvoyait un résultat avec un maximum de six décimales. Si le résultat contenait plus de six décimales, il était tronqué. À partir de Hologres V1.3, la fonction Avg renvoie le résultat avec toutes les décimales complètes.

• La conversion d'une valeur de type DECIMAL en type TEXT a été optimisée. Dans les versions de Hologres antérieures à V1.3.46, la valeur TEXT résultant de la conversion d'une valeur DECIMAL s'affichait en notation scientifique. À partir de Hologres V1.3.46, la valeur TEXT est affichée directement. Exemples d'instructions SQL :

  CREATE TABLE t (a INT, b DECIMAL(38,10));
  INSERT INTO t VALUES (1,1);
  INSERT INTO t VALUES (1,0);
  SELECT a,b,b::text FROM t;
  -- In Hologres V1.3.46 or later, the following result is returned:
  a	|  b	        |b
  --+-------------+------
  1 |0.0000000000	|0.0000000000
  1 |1.0000000000	|1.0000000000
  
  -- In versions earlier than Hologres V1.3.46, the following result is returned:
  a	|  b	        |b
  --+-------------+------
  1 |0.0000000000	|0.E-10
  1 |1.0000000000	|1.0000000000

Modifications du comportement par défaut dans Hologres V1.3 publiées en février 2023

Certaines fonctionnalités ont été optimisées.

À partir de Hologres V1.3.36, vous pouvez créer une vue inter-schémas en utilisant le modèle d'autorisation au niveau du schéma (SLPM). Pour plus d'informations, consultez la rubrique Utiliser le SLPM.

V1.3 (janvier 2023)

Certaines fonctionnalités ont été optimisées.

• À partir de Hologres V2.0, les tables au format segment ne sont plus prises en charge. Dès Hologres V1.3.35, une instruction permet de convertir simultanément plusieurs tables au format segment en tables au format ORC. Cette conversion facilite la migration des données des tables existantes. Pour plus d'informations, consultez la rubrique Mettre à niveau le format de stockage d'une table orientée colonnes. Les instances Hologres contenant des données au format segment ne peuvent pas être mises à niveau vers une version ultérieure.

• À partir de Hologres V1.3.35, davantage de paramètres Grand Unified Configuration (GUC) liés à la fonctionnalité de plan fixe sont définis sur on par défaut. Cela améliore l'utilisabilité et les performances du système. Pour plus de détails, reportez-vous à la rubrique Accélérer l'exécution SQL avec des plans fixes.

V1.3 (décembre 2022)

Certaines fonctionnalités ont été optimisées.

• À compter du December 26, 2022, Alibaba Cloud ne fournit plus de points d'entrée Virtual Private Cloud (VPC) pour les nouvelles instances, y compris celles créées via la fonctionnalité de sauvegarde ou de restauration. Vous pouvez spécifier des points d'entrée VPC plus sécurisés. Le point d'entrée VPC que vous spécifiez est connecté uniquement au VPC sélectionné lors de l'achat de votre instance Hologres, ce qui améliore la sécurité et l'isolation. Les instances existantes ne sont pas affectées. Nous vous recommandons de désactiver le point d'entrée VPC d'origine et d'en spécifier un nouveau à la place.

• Dans Hologres V1.3.31 et versions ultérieures, vous pouvez chiffrer les données dans Hologres et interroger les données chiffrées depuis MaxCompute par défaut. Aucune configuration supplémentaire ni ouverture de ticket n'est nécessaire. Pour plus d'informations, consultez les rubriques Chiffrement des données au repos et Interrogation des données MaxCompute chiffrées.

V1.3 (novembre 2022)

V1.3 (octobre 2022)

V1.3 (septembre 2022)

V1.3 (juillet 2022)

V1.1 (juillet 2022)

V1.1 (avril 2022)

L'utilisation de la mémoire a été optimisée.

Dans Hologres V1.1.53 et versions ultérieures, l'utilisation de la mémoire est optimisée et les métriques d'exploitation et maintenance backend sont rapportées plus efficacement, libérant ainsi davantage de mémoire pour le calcul. Mettez à niveau vers la version V1.1.53 selon vos besoins métier.

V1.1 (mars 2022)

Les performances des requêtes ponctuelles initiées à l'aide de plans fixes ont été optimisées.

Dans Hologres V1.1.49 et versions ultérieures, les performances des requêtes ponctuelles initiées via des plans fixes sont améliorées. Pour les requêtes ponctuelles impliquant un grand volume de données, le débit augmente de plus de 30 %. Vous pouvez mettre à jour la version de votre instance Hologres vers V1.1.49 ou ultérieure selon vos besoins métier. Pour plus d'informations sur les plans fixes, consultez la rubrique Accélération de l'exécution SQL avec des plans fixes.

V1.1 (mars 2022)

Les propriétés sont vérifiées lorsqu'une table enfant est attachée à une table parent.

Dans Hologres V1.1.42 et versions ultérieures, les propriétés d'une table enfant et d'une table parent sont strictement vérifiées après l'envoi d'une demande d'attachement de la table enfant à la table parent. Si une propriété de la table enfant n'est pas cohérente avec celle de la table parent, une erreur est signalée et l'opération d'attachement échoue. Les propriétés vérifiées par le système incluent les clés primaires, les index et la contrainte NOT NULL. Avant de créer une table enfant, assurez-vous que ses propriétés sont cohérentes avec celles de la table parent. Pour plus d'informations, consultez la rubrique CREATE PARTITION TABLE.

-- In this example, the following data definition language (DDL) statements are executed to create a parent table and a child table.
BEGIN;
CREATE TABLE public.hologres_parent(
  a INT,
  b text NOT NULL,
  c timestamptz NOT NULL,
  ds text,
  PRIMARY KEY(a,ds)
)
 PARTITION BY LIST(ds);
CALL set_table_property('public.hologres_parent', 'orientation', 'column');
CALL set_table_property('public.hologres_parent', 'distribution_key', 'a');
CALL set_table_property('public.hologres_parent', 'clustering_key', 'b');
CALL set_table_property('public.hologres_parent', 'event_time_column', 'c');

CREATE TABLE public.hologres_child PARTITION OF public.hologres_parent 
FOR VALUES IN('20201103');

COMMIT;

-- Create a temporary child partitioned table.
BEGIN;
CREATE TABLE IF NOT EXISTS public.tmp_hologres_child(
  a INT,
  b text NOT NULL,
  c timestamptz NOT NULL,
  ds text,
  PRIMARY KEY (a,ds)
);
CALL set_table_property('public.tmp_hologres_child', 'orientation', 'column');
CALL set_table_property('public.tmp_hologres_child', 'distribution_key', 'a');
CALL set_table_property('public.tmp_hologres_child', 'clustering_key', 'a,b');
CALL set_table_property('public.tmp_hologres_child', 'event_time_column', 'c');
COMMIT;

-- Import data from a foreign table to the temporary child partitioned table.
INSERT INTO public.tmp_hologres_child SELECT * FROM foreign_table WHERE ds='20201103';

-- Drop the original child partitioned table and associate the temporary child partitioned table with the parent table.
BEGIN;
DROP TABLE IF EXISTS  public.hologres_child;
ALTER TABLE public.tmp_hologres_child RENAME TO hologres_child;
ALTER TABLE public.hologres_parent ATTACH PARTITION public.hologres_child
FOR VALUES IN ('20201103');
COMMIT ;

-- Error cause.
ERROR: 
partition index hologres_child's immutable properties(e.g. clustering_key, event_time_column) is consistent with parent.  
Hint: create partition with [create table ... partition of ...] to be consistent with parent.                

V1.1 (décembre 2021)

Par défaut, le point d'entrée public d'une nouvelle instance Hologres est désactivé.

Afin de répondre aux exigences de sécurité en matière de contrôle d'accès aux données, les points d'entrée publics des nouvelles instances Hologres sont automatiquement désactivés et les capacités d'accès Internet ne sont pas fournies par défaut à partir du 7 décembre 2021 à 00:00:00. Si vous souhaitez vous connecter à votre instance Hologres via un point d'entrée public, vous pouvez activer le point d'entrée public dans la console Hologres.

V1.1 (novembre 2021)

La mémoire maximale utilisée pour le calcul n'est plus limitée à 20 Go par nœud.

V1.1 (octobre 2021)

• La fonctionnalité auto-analyze est activée par défaut.

  Auto-analyze, introduite dans la version V0.10 et éprouvée en production, est activée par défaut pour les nouvelles instances dans la version V1.1. Les instances mises à niveau conservent leur paramètre existant. Le nom du paramètre a également été modifié dans la version V1.1 :

  Nom du paramètre d'origine	Nouveau nom du paramètre	Valeur par défaut
  hg_experimental_enable_start_auto_analyze_worker	hg_enable_start_auto_analyze_worker	on

  Pour plus d'informations sur l'utilisation de la fonctionnalité auto-analyze, consultez la rubrique ANALYZE et AUTO ANALYZE.

• Le nom d'une fonction liée à un groupe de tables a été modifié.

  La fonctionnalité de resharding, introduite dans la version V0.10 et éprouvée en production, dispose d'une fonction de groupe de tables renommée dans la version V1.1 :

  Nom de la fonction d'origine	Nouveau nom de la fonction
  hg_update_table_shard_count('table_name','table_group_name')	hg_move_table_to_table_group('table_name','table_group_name')

  • Pour plus d'informations sur l'utilisation de la fonctionnalité de resharding, consultez la rubrique Gestion des groupes de tables et des shards.

  • Pour plus d'informations sur l'utilisation des groupes de tables, consultez la rubrique Bonnes pratiques pour la configuration des groupes de tables.

• Le moteur d'accès accéléré aux tables externes MaxCompute dans Hologres a été modifié.

  Un nouveau moteur de table externe MaxCompute, introduit dans la version V0.10, améliore les performances de plus de 30 %. Dans la version V1.1, ce moteur est utilisé par défaut pour les nouvelles instances ; les instances mises à niveau conservent leur moteur existant. Les noms des paramètres ont également été modifiés :

  Nom du paramètre d'origine	Nouveau nom du paramètre	Remarques
  hg_experimental_enable_access_odps_orc_via_holo	hg_enable_access_odps_orc_via_holo	Valeur par défaut : on.
  hg_experimental_foreign_table_executor_max_dop	hg_foreign_table_executor_max_dop	La valeur par défaut est modifiée pour correspondre au nombre de cœurs CPU de l'instance. La valeur maximale est 128.
  Aucun	hg_foreign_table_executor_dml_max_dop	Ce paramètre a été ajouté dans Hologres V1.1. La valeur par défaut est 32. Ce paramètre s'applique aux instructions DML liées aux tables externes.
  hg_experimental_foreign_table_split_size	hg_foreign_table_split_size	Valeur par défaut : 64. Unité : Mo.
  hg_experimental_foreign_table_max_partition_limit	hg_foreign_table_max_partition_limit	La valeur par défaut est 512. Cette valeur indique qu'un maximum de 512 partitions peuvent être analysées pour une requête.
  hg_experimental_enable_write_maxcompute	Aucun	Dans Hologres V1.1, la valeur par défaut est on. La valeur on indique que les données peuvent être écrites dans MaxCompute. Pour plus d'informations, consultez la rubrique Exportation des données vers MaxCompute.

  Pour plus d'informations sur les paramètres, consultez la rubrique Accélération des requêtes MaxCompute.

• La table pg_stat_activity enregistre l'état des connexions actives pour tous les nœuds frontend.

  Dans les versions antérieures à V1.1, pg_stat_activity enregistrait les connexions actives pour un seul nœud FE. Dans la version V1.1, elle couvre tous les nœuds FE. Pour plus d'informations sur la gestion des requêtes actives à l'aide de la table pg_stat_activity, consultez la rubrique Gestion des requêtes.

• Le mécanisme de gestion des connexions a été ajusté.

  Dans Hologres V1.1 et versions ultérieures, des connexions sont réservées pour le superutilisateur et la logique du pool de connexions HoloWeb est optimisée. Le superutilisateur peut utiliser HoloWeb pour gérer ou libérer des connexions lorsque la limite de connexions est dépassée. Pour plus d'informations, consultez la rubrique Gestion des connexions.

• La valeur par défaut du paramètre idle_in_transaction_session_timeout a été modifiée.

  Le paramètre idle_in_transaction_session_timeout spécifie le délai d'expiration pour les transactions inactives. Sans ce paramètre, les transactions expirées ne sont pas annulées, ce qui risque de provoquer des interblocages. Dans la version V1.1, idle_in_transaction_session_timeout est défini par défaut sur 10 minutes. Pour plus d'informations, consultez la rubrique Gestion des requêtes.