Hologres:ANALYZE and AUTO ANALYZE

Pourquoi les statistiques sont-elles nécessaires ?

L'optimiseur s'appuie sur les statistiques de tables et de colonnes pour générer des plans d'exécution pertinents, notamment :

• Le nombre de lignes et le nombre de colonnes ;

• La largeur des colonnes (Width) ;

• Le nombre de valeurs distinctes (NDV) ;

• Les valeurs les plus courantes (MCV) et leurs fréquences ;

• L'histogramme et d'autres caractéristiques de distribution.

Ces informations guident l'optimiseur pour :

• Estimer le coût d'exécution des opérateurs ;

• Réduire l'espace de recherche du plan d'exécution ;

• Sélectionner l'ordre de jointure et les algorithmes de jointure appropriés ;

• Estimer la mémoire nécessaire et le degré de parallélisme.

Il en résulte un plan d'exécution plus optimal.

La commande ANALYZE constitue la méthode standard permettant aux utilisateurs de collecter activement les statistiques de tables et de colonnes. En l'absence de statistiques ou lorsque celles-ci sont inexactes, le plan de requête peut se dégrader considérablement, par exemple en raison d'un ordre de jointure anormal, ce qui se traduit par : une erreur OOM lors de la requête, un temps d'exécution prolongé ou une consommation CPU élevée de l'instance.

AUTO ANALYZE représente la méthode standard utilisée par le système Hologres pour collecter automatiquement les statistiques de tables et de colonnes. Puisqu'AUTO ANALYZE est un processus asynchrone en arrière-plan, il existe un délai de quelques dizaines de secondes à plusieurs minutes entre la modification des données de la table et la découverte, la planification et la finalisation de la collecte automatique des statistiques par AUTO ANALYZE. Par conséquent, dans certains scénarios spécifiques, il est recommandé d'exécuter manuellement la commande ANALYZE afin de garantir une collecte rapide des statistiques.

Quand exécuter manuellement la commande ANALYZE ?

Il est recommandé d'effectuer une exécution manuelle dans les scénarios suivants :

• Après des opérations INSERT / UPDATE / DELETE qui importent, mettent à jour ou suppriment un grand volume de données dans une table, et si cette table doit être interrogée immédiatement, il est conseillé d'exécuter ANALYZE sur la table après l'opération INSERT / UPDATE / DELETE ;

• Lorsque les performances des jointures multi-tables se dégradent significativement, exécutez ANALYZE au niveau des colonnes sur les colonnes de jointure clés et les colonnes utilisées dans les clauses GROUP BY ;

• Après avoir exécuté CREATE FOREIGN TABLE ou IMPORT FOREIGN SCHEMA pour une table externe, et si celle-ci doit être interrogée immédiatement, il est recommandé d'exécuter ANALYZE sur la nouvelle table externe avant de lancer les requêtes afin de collecter les statistiques initiales ;

• Après avoir exécuté CREATE EXTERNAL DATABASE, et si les données doivent être interrogées immédiatement, il est conseillé d'exécuter ANALYZE sur les tables de la base de données externe qui seront interrogées avant de lancer les requêtes ;

• Lorsque l'une des erreurs ou symptômes suivants survient :

  • Erreur OOM lors d'une jointure multi-tables : Query executor exceeded total memory limitation ..., ou Query exceed per query memory limitation ... ;

  • Erreur lors d'une jointure multi-tables : Capacity error: BinaryArray cannot contain more than 2147483646 bytes ... ;

  • Les tâches d'importation ou de requête s'exécutent anormalement longtemps avec une utilisation inégale du CPU.

  • La commande EXPLAIN <SQL> affiche un opérateur Scan avec une estimation de 1 000 lignes, -> Seq Scan on tbl (cost=0.00..5.00 rows=1000 width=1) ; cela indique que la table manque de statistiques.

  • La commande EXPLAIN <SQL> affiche un opérateur Scan avec une estimation d'une seule ligne, -> Seq Scan on tbl (cost=0.00..1.00 rows=1 width=1) ; cela signifie que la table est estimée à 0 ligne. Si le résultat réel du Scan n'est pas nul, les statistiques sont probablement obsolètes et une commande ANALYZE manuelle est recommandée.

Dans les scénarios ci-dessus, il est généralement recommandé de commencer par exécuter manuellement la commande ANALYZE et d'observer si les performances se rétablissent, avant d'ajuster davantage la configuration d'AUTO ANALYZE.

Syntaxe de base et comportement

• Collecter les statistiques pour toutes les colonnes de l'ensemble de la table

ANALYZE table_name;

• Collecte le nombre de lignes de la table et recueille uniformément les statistiques Width, MCV, Histogram, NDV et autres pour toutes les colonnes régulières de la table ;

• Utilise une approche basée sur l'échantillonnage pour estimer diverses valeurs statistiques. L'opération d'échantillonnage lance une sous-requête SQL d'échantillonnage au sein du processus ANALYZE.

• Par défaut, ANALYZE échantillonne aléatoirement 30 000 lignes de la table pour la collecte et le calcul des statistiques. Si la table contient moins de 30 000 lignes, toutes les lignes sont échantillonnées.

• Collecter les statistiques uniquement pour des colonnes spécifiques (recommandé pour les colonnes clés)

ANALYZE table_name(col1, col2, ...);

• Calcule une valeur NDV plus précise pour les colonnes spécifiées (généralement en utilisant la logique APPROX_COUNT_DISTINCT), ce qui est plus précis que l'échantillonnage au niveau de la table mais plus coûteux ;

• Les statistiques MCV, Histogram, Width et autres sont toujours obtenues par échantillonnage ;

• Lorsque la commande ANALYZE est exécutée plusieurs fois sur la même colonne, l'exécution suivante écrase les anciennes statistiques de cette colonne, sans affecter les autres colonnes non spécifiées.

Limites et considérations

• Quelles colonnes ne seront pas analysées

  • Types non pris en charge : Lorsqu'un type de colonne est un type défini par l'utilisateur (User Defined Type) ou n'appartient pas à l'ensemble des types pris en charge par Hologres pour les statistiques, la collecte des statistiques est ignorée :

    • Les types de colonnes qui ne prennent pas en charge ANALYZE incluent : "char" (type caractère unique), BIT, VARBIT, BYTEA, NAME, JSON, TSVECTOR, TSQUERY, OID, XID, CID, INET, POINT, LINE, LSEG, BOX, CIRCLE, PATH, POLYGON, BITARRAY, VARBITARRAY, BYTEAARRAY, INT2ARRAY, MONEYARRAY, NUMERICARRAY, TIMEARRAY, TIMETZARRAY, TIMESTAMPTZARRAY, TIMESTAMPARRAY, ANYARRAY, REGCLASS, DATEARRAY ou autres types INTERNAL.

    • Lorsque le type de colonne n'est pas pris en charge, les commandes ANALYZE manuelles et AUTO ANALYZE sont ignorées ;

    • Pour les tables partitionnées, les types de colonnes qui ne prennent pas en charge la fusion incrémentielle des statistiques de partition ne seront pas non plus analysés. Outre les types listés ci-dessus, les types non pris en charge incluent également : BOOLARRAY, INT4ARRAY, TEXTARRAY, BPCHARARRAY, VARCHARARRAY, INT8ARRAY, FLOAT4ARRAY, FLOAT8ARRAY.

  • Colonnes marquées comme supprimées : Les colonnes logiques conservées après une commande ALTER TABLE ... DROP COLUMN (attisdropped = true) ne seront pas analysées ;

  • Désactivation explicite via l'attribut de colonne :

    • Les colonnes dont l'attribut est défini sur enable_analyze = false ne seront pas traitées par ANALYZE ni par AUTO ANALYZE ;

    • Les colonnes dont l'attribut est défini sur enable_auto_analyze = false ne seront pas traitées par AUTO ANALYZE.

    • Pour plus de détails sur ces attributs de colonne, consultez les sections suivantes.

  • Statistiques des colonnes JSONB non activées :

    • Si le type de colonne est JSONB et que enable_jsonb_stats n'est pas activé, les statistiques JSONB ne seront pas collectées pour cette colonne ;

    • Si vous devez vous appuyer sur les statistiques des colonnes JSONB (par exemple, pour des conditions de filtrage JSON complexes), vous devez d'abord activer enable_jsonb_stats dans les attributs de la colonne.

• Limites de la commande ANALYZE pour les tables Data Lake

  • ANALYZE n'est pas pris en charge pour un Timestamp, une Version, une Branch, un Snapshot ou un Tag spécifique individuellement.

Utilisation typique

• Utilisation typique recommandée

  • Exécutez ANALYZE au niveau des colonnes sur les colonnes de jointure, les colonnes GROUP BY et les colonnes utilisées dans les conditions de filtrage :

ANALYZE tablename (order_id, user_id, dt);

• • Après une importation ou une mise à jour par lots, exécutez la commande sur les tables fortement impactées :

ANALYZE tablename;

• • Exécutez la commande sur les tables externes (FOREIGN TABLE / IMPORT FOREIGN SCHEMA / tables sous EXTERNAL DATABASE) avant la première requête :

ANALYZE foreign_table;

• Ignorer la collecte de statistiques pour des colonnes spécifiques en définissant des attributs de colonne

  • Hologres permet de contrôler l'exécution de ANALYZE ou d'AUTO ANALYZE sur une colonne via des attributs au niveau de la colonne, ce qui s'applique aux scénarios suivants :

    • Les colonnes ultra-larges (telles que les textes très longs) engendrent un coût élevé de collecte des statistiques, et leur analyse apporte un bénéfice limité, voire nul, au plan de requête ;

    • Certaines colonnes ne participent jamais aux jointures, au filtrage ou à l'agrégation, et n'ont donc pas besoin de collecte de statistiques ;

    • Besoin de réduire la consommation de ressources liée à ANALYZE ou AUTO ANALYZE.

  • Les paramètres de contrôle sont les options de colonne suivantes :

    • enable_analyze : Contrôle si la colonne participe à ANALYZE manuel et à AUTO ANALYZE automatique. La valeur par défaut est true ;

    • enable_auto_analyze : Contrôle uniquement si la colonne participe à AUTO ANALYZE automatique. La valeur par défaut est true.

  • Méthode de définition (via la commande ALTER TABLE) :

-- Disable ANALYZE and AUTO ANALYZE for a specific column
ALTER TABLE t ALTER COLUMN bitmap_col SET (enable_analyze = false);

-- Disable AUTO ANALYZE for a specific column while still allowing manual ANALYZE
ALTER TABLE t ALTER COLUMN large_text_col SET (enable_auto_analyze = false);

-- Restore default behavior (re-enable)
ALTER TABLE t ALTER COLUMN bitmap_col RESET (enable_analyze);
ALTER TABLE t ALTER COLUMN large_text_col RESET (enable_auto_analyze);

• • Considérations :

    • Après avoir défini enable_analyze = false, la colonne sera automatiquement ignorée lors de l'exécution de la commande ANALYZE table_name;, mais elle pourra toujours faire l'objet d'une collecte explicite via la commande manuelle ANALYZE table_name(col); ;

    • Après avoir défini enable_auto_analyze = false, la colonne ne sera pas collectée par AUTO ANALYZE, mais elle pourra toujours faire l'objet d'une collecte explicite via la commande manuelle ANALYZE table_name(col); ;

    • Si une colonne a un impact significatif sur le plan de requête (comme les colonnes de jointure ou les colonnes de condition de filtrage), il n'est pas recommandé de désactiver la collecte de ses statistiques.

Scénarios et limites

• Dans Hologres V2.0 et versions ultérieures, l'ANALYZE incrémentiel des partitions est activé par défaut sans configuration manuelle. Pour plus de détails, reportez-vous aux notes de version du produit ;

• Lorsqu'il est activé, l'exécution de la commande ANALYZE sur une partition enfant tentera de combiner ses statistiques avec celles des autres partitions enfants pour produire les statistiques de la table parente ;

• La condition préalable à la fusion des statistiques de la table parente est que, hormis la partition enfant en cours d'analyse, toutes les autres partitions enfants sous la table parente doivent déjà disposer de statistiques (y compris les statistiques de nombre de lignes et les statistiques de colonnes) ;

• Par conséquent, vous pouvez :

  • Lors de la configuration initiale, exécuter d'abord la commande ANALYZE sur la table parente. Le système détectera automatiquement les partitions enfants nécessitant une commande ANALYZE et les analysera une par une, en fusionnant finalement les résultats dans les statistiques de la table parente ;

  • Lors de l'ajout de nouvelles partitions par la suite, il suffit d'exécuter la commande ANALYZE sur les partitions enfants nouvellement ajoutées.

Exemple succinct

BEGIN;
DROP TABLE IF EXISTS t_parent;
CREATE TABLE t_parent(a int, b int) PARTITION BY LIST (a);
CREATE TABLE child1 PARTITION OF t_parent FOR VALUES IN (1);
CREATE TABLE child2 PARTITION OF t_parent FOR VALUES IN (2);
COMMIT;
insert into child1 values (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 2);
insert into child2 values (2, 1), (2, 2), (2, 3), (2, 4), (2, 5), (2, 5), (2, 5), (2, 5), (2, 5), (2, 5);

-- child2 lacks statistics, so parent table statistics cannot be merged
dbname=# ANALYZE child1;
INFO:  auto merging of leaf partition stats to calculate root partition stats is not possible because partition child2 is not analyzed
ANALYZE

-- child1 already has statistics. After analyzing child2, parent table statistics can be automatically merged
dbname=# ANALYZE child2;
ANALYZE

dbname=# SELECT tablename,
       attname,
       null_frac         AS "NF",
       avg_width,
       n_distinct,
       most_common_vals  AS "MCV",
       most_common_freqs AS "MCV_FRAQ"
FROM   pg_stats
WHERE  tablename = 't_parent';

 tablename | attname | NF | avg_width | n_distinct |  MCV  |  MCV_FRAQ
-----------+---------+----+-----------+------------+-------+------------
 t_parent  | a       |  0 |         4 |          2 | {1,2} | {0.5,0.5}
 t_parent  | b       |  0 |         4 |       -0.2 | {1,5} | {0.45,0.3}
(2 rows)

-- After this, when new partitions are added, you only need to ANALYZE the child partition. Parent table statistics will be automatically merged through sampling the child partition only.

Commande ANALYZE sur la table parente

Il arrive que plusieurs partitions enfants d'une table partitionnée aient subi des modifications de données et que vous ne souhaitiez pas exécuter ANALYZE sur chaque partition enfant individuellement. Dans ce cas, vous pouvez effectuer un seul ANALYZE sur la table parente.

Lorsque l'ANALYZE incrémentiel des partitions est activé, l'exécution manuelle de ANALYZE sur la table parente amène le système à sélectionner de manière adaptative les partitions enfants nécessitant une mise à jour des statistiques, plutôt que d'analyser aveuglément toutes les partitions enfants. Ce mécanisme réduit considérablement le coût de l'ANALYZE pour les grandes tables partitionnées tout en garantissant la précision des statistiques.

-- Execute ANALYZE on the parent table
ANALYZE partition_parent_table;

INFO:  will analyze 5 part tables first (stats changed 3, unable-to-merge 2)

Commande ANALYZE pour les tables partitionnées logiques

Une table partitionnée logique est un type de table partitionnée propre à Hologres. Contrairement aux tables partitionnées PostgreSQL standard (qui créent des tables enfants physiques via PARTITION BY), une table partitionnée logique reste physiquement une table unique et ne partitionne les données que logiquement en fonction des valeurs des colonnes de partition, offrant ainsi des capacités de gestion de partition plus flexibles.

La logique ANALYZE pour les tables partitionnées logiques est essentiellement la même que pour les tables partitionnées physiques. La seule différence réside dans le fait que les partitions enfants d'une table partitionnée logique ne sont pas des tables séparées, mais comme les partitions enfants physiques, elles possèdent chacune leurs propres statistiques de nombre de lignes et de colonnes indépendantes.

-- Create a logical partitioned table
CREATE TABLE user_events (
    user_id INT NOT NULL,
    event_type TEXT NOT NULL,
    event_date DATE NOT NULL,
    event_data INT
)
LOGICAL PARTITION BY LIST(user_id, event_date);

-- Insert data into different logical partitions
INSERT INTO user_events SELECT 1, 'login', '2024-11-01', i FROM generate_series(1, 1000) i;
INSERT INTO user_events SELECT 1, 'logout', '2024-11-02', i FROM generate_series(1, 1000) i;
INSERT INTO user_events SELECT 2, 'purchase', '2024-11-03', i FROM generate_series(1, 1000) i;
INSERT INTO user_events SELECT 3, 'view', '2024-11-04', i FROM generate_series(1, 1000) i;

-- Execute ANALYZE on the parent table
ANALYZE VERBOSE user_events;

INFO:  will analyze 4 logical partitions first
INFO:  analyzing hologres table "public.user_events" PARTITION (user_id=1,event_date='2024-11-01')
INFO:  analyzing hologres table "public.user_events" PARTITION (user_id=1,event_date='2024-11-02')
INFO:  analyzing hologres table "public.user_events" PARTITION (user_id=2,event_date='2024-11-03')
INFO:  analyzing hologres table "public.user_events" PARTITION (user_id=3,event_date='2024-11-04')
INFO:  try to merge root partition
INFO:  automatically merging leaf partition stats to calculate root partition stats

-- Execute ANALYZE on a single logical partition
ANALYZE user_events PARTITION (user_id=1, event_date='2024-11-01');

-- Execute ANALYZE on multiple logical partitions
ANALYZE user_events
    PARTITION (user_id=1, event_date='2024-11-01')
    PARTITION (user_id=2, event_date='2024-11-03');

-- Execute ANALYZE on specific columns of a specified logical partition
ANALYZE user_events
    PARTITION (user_id=1, event_date='2024-11-01') (user_id, event_type);

SELECT
    unique_name,
    schema_name,
    table_name,
    total_rows,
    sample_rows,
    nattr
FROM hologres_statistic.hg_table_statistic
WHERE table_name = 'user_events'
ORDER BY unique_name;

| unique_name | schema_name | table_name | total_rows | sample_rows | nattr |
|-------------|-------------|------------|------------|-------------| ----- |
| user_events | public | user_events | 4000 | 0 | 4 |
| user_events.a1b2c3d4e5f6... | public | user_events | 1000 | 1000 | 4 |
| user_events.f6e5d4c3b2a1... | public | user_events | 1000 | 1000 | 4 |
| user_events.1234567890ab... | public | user_events | 1000 | 1000 | 4 |
| user_events.abcdef123456... | public | user_events | 1000 | 1000 | 4 |

Commutateur et portée

-- Check whether AUTO ANALYZE is enabled for the current database
SHOW hg_enable_start_auto_analyze_worker;

-- Disable (use only for temporary troubleshooting)
ALTER DATABASE dbname SET hg_enable_start_auto_analyze_worker = OFF;

-- Reset to the default value ON (recommended)
ALTER DATABASE dbname RESET hg_enable_start_auto_analyze_worker;

ALTER TABLE my_table SET (autovacuum_enabled = false);

-- Recommended: reset to restore the default
ALTER TABLE my_table RESET (autovacuum_enabled);

-- Or explicitly set to true (not recommended)
ALTER TABLE my_table SET (autovacuum_enabled = true);

SELECT relname, reloptions FROM pg_class WHERE relname = 'my_table';

 relname  |         reloptions
----------+----------------------------
 my_table | {autovacuum_enabled=false}
(1 row)

-- Disable AUTO ANALYZE for a specific column while still allowing manual ANALYZE
ALTER TABLE t ALTER COLUMN large_text_col SET (enable_auto_analyze = false);

-- Restore default behavior (re-enable)
ALTER TABLE t ALTER COLUMN large_text_col RESET (enable_auto_analyze);

Logique de déclenchement d'AUTO ANALYZE

AUTO ANALYZE combine plusieurs types de signaux pour déterminer si les statistiques doivent être mises à jour pour une table donnée :

1. Volume de modifications des données

   • S'applique uniquement aux tables Hologres régulières (hors tables externes) ;

   • Toutes les 1 minute, le FE collecte le nombre de lignes concernées par les opérations INSERT/UPDATE/DELETE observées sur chaque table. Si la modification dépasse le seuil, un AUTO ANALYZE est déclenché (réponse rapide) ;

   • Toutes les 10 minutes, le système récupère les nombres de lignes modifiées (insertion/mise à jour/suppression) depuis le moteur de stockage. Si la modification dépasse le seuil, un AUTO ANALYZE est déclenché (calibrage précis) ;

2. Modifications du schéma

   • S'applique uniquement aux tables Hologres régulières (hors tables externes) ;

   • Toutes les 1 minute, le système identifie les tables présentant les modifications suivantes et exécute un AUTO ANALYZE :

     • ADD / DROP COLUMN ;

     • Pour les tables partitionnées (y compris les tables de partition logique) : ATTACH / DETACH des partitions enfants.

3. Statistiques manquantes / Impossibilité de fusionner les statistiques de la table de partition parente

   • S'applique aux tables Hologres régulières et aux tables externes ;

   • Toutes les 1 minute, le système identifie les tables/colonnes dont les statistiques sont manquantes et les partitions enfants qui ne remplissent pas les conditions pour la fusion incrémentielle des statistiques.

4. Tables externes

   • S'applique uniquement aux tables externes introduites via CREATE FOREIGN TABLE, IMPORT FOREIGN SCHEMA ou le mécanisme Auto Load dans des contextes autres que External Database ;

   • Prend actuellement en charge l'AUTO ANALYZE uniquement pour les tables externes MaxCompute ;

   • Toutes les 4 heures, le système vérifie périodiquement toutes les tables externes de la base de données. Entre deux vérifications, si des modifications de données externes sont détectées (le critère étant que le last_modify_timestamp de la table externe correspondante se situe entre les deux intervalles de vérification), un AUTO ANALYZE est déclenché.

5. Statistiques de secours

   • Pendant la fenêtre horaire 01:00-05:00, un AUTO ANALYZE « de secours » est exécuté sur les tables présentant des modifications continues mais n'ayant pas déclenché le seuil (> 5 000 lignes modifiées, < 10 % du volume de modifications). Cela permet de capturer la dérive de la distribution des données dans les colonnes (par exemple, des champs de type date écrits après minuit le lendemain, complètement différents de la veille, entraînant des changements de distribution).

6. Tables fréquemment accédées (External Database uniquement)

   • Après activation du paramètre enable_auto_analyze sur une External Database, le système Hologres commence à suivre les tables récemment accédées depuis le dernier démarrage du système et les ajoute à la liste d'observation ;

   • Toutes les 1 heure, les tables de la liste d'observation « fréquemment accédées récemment » déclenchent un AUTO ANALYZE ;

   • Notez qu'après un redémarrage du système, la liste des tables accédées est effacée et l'enregistrement reprend depuis le début.

AUTO ANALYZE pour External Database

• À partir de Hologres V3.0, Hologres prend en charge la fonctionnalité External Database. Lors de la création d'une External Database, vous pouvez activer AUTO ANALYZE (désactivé par défaut, voir les notes de version pour plus de détails) :

-- Enable AUTO ANALYZE when creating an External Database
-- Reference: https://www.alibabacloud.com/help/zh/hologres/developer-reference/create-external-database
CREATE EXTERNAL DATABASE <ext_database_name> WITH
  metastore_type 'maxcompute'
  mc_project 'project_name'
  enable_auto_analyze 'true';

-- Enable AUTO ANALYZE for an existing External Database
ALTER EXTERNAL DATABASE dbname WITH enable_auto_analyze 'true';

• La portée metastore_type prise en charge par AUTO ANALYZE sur External Database est : dlf, dlf-paimon, dlf-rest, maxcompute.

• Les formats de table pris en charge par AUTO ANALYZE sur External Database incluent : MaxCompute, Paimon, Iceberg.

• L'AUTO ANALYZE sur External Database utilise par défaut l'identité Owner de l'External Database et emploie l'authentification par mot de passe unique basé sur le temps (TOTP) pour exécuter les tâches ANALYZE. Si le Owner ne dispose pas des autorisations suffisantes sur la table, le système ne peut pas exécuter correctement les tâches AUTO ANALYZE.

• Pour qu'une table externe dans une External Database soit éligible à l'AUTO ANALYZE, les conditions suivantes doivent être remplies :

  • La configuration de l'External Database hg_enable_start_auto_analyze_worker = on ; (activé par défaut)

  • L'attribut de l'External Database enable_auto_analyze est défini sur true (non configuré par défaut, ce qui signifie false, voir les notes de version pour plus de détails)

  • Le Owner de l'External Database doit disposer des autorisations de requête pour le projet Data Lake (le cas échéant) et la table

  • La table doit avoir été accédée au moins une fois au cours des 3 derniers jours

    • L'AUTO ANALYZE sous External Database surveille uniquement les tables externes ayant été accédées au moins une fois ;

    • Après un redémarrage du système, si une table externe est accédée au moins une fois, le système AUTO ANALYZE l'ajoute à la liste d'observation et déclenche périodiquement l'AUTO ANALYZE pour ces tables ;

Limites de ressources d'AUTO ANALYZE

Afin d'éviter que les tâches AUTO ANALYZE en arrière-plan n'impactent les tâches utilisateur au premier plan, Hologres a établi les limites de ressources suivantes pour la fonctionnalité AUTO ANALYZE :

• Lors de l'exécution des tâches AUTO ANALYZE, la limite de mémoire par worker est par défaut de 4 GB. Si le volume de données de la table est trop important, l'échantillonnage peut dépasser la limite de mémoire, entraînant l'échec de la requête SQL d'échantillonnage AUTO ANALYZE. Dans ce cas, seules les informations sur le nombre de lignes peuvent être collectées, et non les informations de distribution des colonnes (MCV, Histogramme, NDV, etc.). Vous pouvez ajuster auto_analyze_work_memory_mb pour modifier ce comportement. Plus la spécification de l'instance est élevée, plus la limite de mémoire disponible pour AUTO ANALYZE est importante.

• La concurrence au niveau de l'instance pour les tâches AUTO ANALYZE planifiées simultanément ne dépasse généralement pas 4, et ne dépasse jamais 6 dans les cas extrêmes.

• Pour les tâches AUTO ANALYZE des partitions enfants sous la même table partitionnée, la concurrence maximale de planification simultanée est de 3.

• Par défaut, AUTO ANALYZE collecte les statistiques pour les 256 premières colonnes. Si une table comporte plus de 256 colonnes, seules les 256 premières sont collectées (pour les tables partitionnées, les colonnes de partition sont prioritaires et seront collectées même si elles se situent au-delà de la position 256). Vous pouvez ajuster hg_experimental_auto_analyze_max_columns_count pour modifier cette valeur.

• Les sous-requêtes SQL d'échantillonnage des tâches AUTO ANALYZE s'exécutent à l'aide d'un pool d'arrière-plan à faible priorité, avec une concurrence limitée au niveau de l'exécution des requêtes. Par conséquent, les tâches AUTO ANALYZE prennent plus de temps que l'ANALYZE manuel, ce qui ne devrait pas inquiéter les utilisateurs.

• Pour les tables externes, AUTO ANALYZE collecte uniquement les statistiques de colonne pour les colonnes de partition (par exemple, MCV). Il n'effectue pas d'échantillonnage pour collecter les statistiques de colonne des autres colonnes que les colonnes de partition.

Paramètres configurables d'AUTO ANALYZE

Par défaut, la fonctionnalité Hologres AUTO ANALYZE ne nécessite aucune modification de paramètre.

Dans de rares scénarios métier (telles que des écritures/mises à jour de données peu fréquentes, des charges de travail de requête n'ayant pas besoin de statistiques, ou une augmentation de la charge système causée par AUTO ANALYZE), les utilisateurs peuvent modifier certains paramètres par défaut pour ajuster le comportement d'AUTO ANALYZE à des fins d'intervention ou d'optimisation partielle des performances.

-- Superuser: modify the default AUTO ANALYZE parameters at the database level
ALTER DATABASE dbname SET <GUC> = <values>;

Commutateur

Comment activer l'estimation rapide du nombre de lignes :

-- Disable (use only for temporary troubleshooting or when statistics are not needed for the entire database)
ALTER DATABASE dbname SET hg_experimental_get_fast_num_of_rows = OFF;

-- V3.2 and later: enable (reset to the default value)
ALTER DATABASE dbname RESET hg_experimental_get_fast_num_of_rows;

-- V3.1 and earlier: enable
ALTER DATABASE dbname SET hg_experimental_get_fast_num_of_rows = ON;

Limites d'utilisation

• L'estimation rapide du nombre de lignes s'applique aux tables régulières (y compris les tables partitionnées), aux tables externes dans External Database et à d'autres scénarios.

• Le nombre de lignes estimé par la fonctionnalité d'estimation rapide n'est pas garanti d'être entièrement exact. Par exemple, pour des raisons de performance, sur les tables partitionnées Hologres, seules les statistiques de nombre de lignes provenant d'un maximum de 60 partitions (par défaut) sont utilisées pour estimer le nombre total de lignes de la table partitionnée.

• Dans les versions V4.1.15 et antérieures, l'estimation rapide du nombre de lignes n'est pas activée par défaut pour les types de table externe (Foreign Table). Elle peut être activée via le paramètre hg_experimental_enable_foreign_table_get_fast_num_of_rows. Elle est activée par défaut dans les versions V4.1.16 et ultérieures.

• Pour les types de table externe, l'estimation rapide du nombre de lignes prend uniquement en charge les tables externes MaxCompute, les tables externes Paimon et les tables externes Iceberg.

Exemples

1. Exemple hg_experimental_get_fast_num_of_rows

Si une table ne possède pas de statistiques, l'activation de l'estimation rapide du nombre de lignes peut fournir des comptes de lignes plus précis. (Activé par défaut dans Hologres V3.2 et ultérieur)

-- V3.2+
create table test_tbl (a int);
insert into test_tbl select * from generate_series (1, 999);

-- Accurate row count estimation (rows=999)
explain select count(1) from test_tbl ;
                                       QUERY PLAN
----------------------------------------------------------------------------------------
 Final Aggregate  (cost=0.00..5.00 rows=1 width=8)
   ->  Gather  (cost=0.00..5.00 rows=10 width=8)
         ->  Partial Aggregate  (cost=0.00..5.00 rows=10 width=8)
               ->  Local Gather  (cost=0.00..5.00 rows=20 width=8)
                     ->  Partial Aggregate  (cost=0.00..5.00 rows=20 width=8)
                           ->  Seq Scan on test_tbl  (cost=0.00..5.00 rows=999 width=1)

Voici un cas réel en production :

Sans cette fonctionnalité activée, si une table ne possède pas de statistiques, le nœud Scan du plan de requête affichera rows=1000 (indiquant l'absence de statistiques disponibles, et le plan est généré sur la base d'une estimation par défaut de 1 000 lignes).

Après activation de cette fonctionnalité, si une table ne possède pas de statistiques, les lignes du nœud Scan dans le plan de requête ne seront pas égales à 1 000 (le système a appelé les métadonnées du moteur de stockage sous-jacent pour obtenir le nombre de lignes de la table).

Paramètres configurables pour l'estimation rapide du nombre de lignes

Comment identifier les enregistrements ANALYZE et AUTO ANALYZE dans le journal des requêtes

ANALYZE et AUTO ANALYZE, ainsi que leurs requêtes SQL d'échantillonnage, sont enregistrés séparément dans le journal des requêtes.

Les enregistrements d'exécution présentent les caractéristiques suivantes dans le journal des requêtes :

ANALYZE et sa requête SQL d'échantillonnage sont associées via les commentaires dans le champ query, ou via extended_info->>'source_query_id'.

SELECT query_id,
       extended_info->>'src_query_id' as "source query id",
       application_name,
       status,
       duration
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 hour'
  AND  application_name IN ('AutoAnalyze', 'Hologres SQL Generated BY AUTO ANALYZE')
ORDER BY query_start DESC
LIMIT  2;
      query_id       |   source query id   |            application_name            | status  | duration
---------------------+---------------------+----------------------------------------+---------+----------
 1004019226350863009 | 1004019226350778807 | Hologres SQL Generated BY AUTO ANALYZE | SUCCESS |      119
 1004019226350778807 |                     | AutoAnalyze                            | SUCCESS |     3276

Exemples de requêtes

• Consulter les récents enregistrements d'exécution d'AUTO ANALYZE

SELECT usename,
       status,
       duration,
       query_start,
       query_end,
       query,
       application_name
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 hour'
  AND  application_name IN ('AutoAnalyze')
ORDER BY query_start DESC
LIMIT  20;

       query_id,
       extended_info->>'src_query_id' as "source query id"

• Consulter l'historique d'exécution d'AUTO ANALYZE pour une table spécifique

SELECT status,
       duration,
       query_start,
       query
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 day'
  AND  application_name IN ('AutoAnalyze')
  AND  query LIKE '%my_table_name%'
ORDER BY query_start DESC;

• Résumer l'aperçu de l'exécution d'AUTO ANALYZE pour les 3 derniers jours

SELECT query_date,
       status,
       COUNT(*)          AS task_count,
       AVG(duration)     AS avg_duration_ms,
       MAX(duration)     AS max_duration_ms
FROM   hologres.hg_query_log
WHERE  query_start >= CURRENT_DATE::timestamptz - interval '2 day'
  AND  application_name IN ('AutoAnalyze')
  AND  command_tag = 'ANALYZE'
  AND  (status = 'SUCCESS' OR (
            message NOT LIKE '%does not exist%'
        AND message NOT LIKE '%retry later%'))
GROUP BY query_date, status
ORDER BY query_date DESC;

• Consulter les tâches AUTO ANALYZE ayant échoué au cours de la dernière journée

SELECT query_start,
       duration,
       message,
       query
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 day'
  AND  application_name IN ('AutoAnalyze', 'Hologres SQL Generated BY AUTO ANALYZE')
  AND  status != 'SUCCESS'
  AND  (message NOT LIKE '%does not exist%'
        AND message NOT LIKE '%retry later%')
ORDER BY query_start DESC;

Remarques

• Étant donné que les connexions AUTO ANALYZE sont initiées avec une identité d'administrateur interne, les utilisateurs réguliers ont besoin du rôle pg_read_all_stats ou des privilèges d'administrateur de base de données pour consulter les enregistrements d'exécution complets d'AUTO ANALYZE.

• Si vous constatez l'absence d'enregistrements AUTO ANALYZE dans le journal des requêtes pendant une période prolongée, il est recommandé de vérifier si le commutateur AUTO ANALYZE est activé.

Consultation des statistiques de table (hologres_statistic.hg_table_statistic)

Les statistiques de table sont stockées dans la table hologres_statistic.hg_table_statistic et peuvent également être observées dans les tables système.

1. Interrogez cette table pour obtenir les statistiques du dernier ANALYZE.

SELECT schema_name,                -- Table schema
       table_name,                 -- Table name
       user_name,                  -- User who last ran ANALYZE
       schema_version,             -- Table schema version at last ANALYZE
       total_rows,                 -- Row count at last ANALYZE
       sample_rows,                -- Sample rows used at last ANALYZE
       analyze_timestamp,          -- Completion time of last ANALYZE
       analyze_count               -- Total ANALYZE count so far
FROM   hologres_statistic.hg_table_statistic
WHERE  unique_name = hologres.hg_internal_statistic_unique_name ('schemaname', 'tablename')
ORDER BY analyze_timestamp DESC;

-- Sample output
 schema_name | table_name |    user_name     | schema_version | total_rows | sample_rows |  analyze_timestamp  | analyze_count
-------------+------------+------------------+----------------+------------+-------------+---------------------+---------------
 public      | test_fnr   |   BASIC$test_fnr |             -1 |        999 |         999 | 2026-03-02 22:05:29 |             2
(1 row)

V3.1 et antérieure :

• Chaque table possède de 0 à n enregistrements dans la table hologres_statistic.hg_table_statistic. 0 enregistrement signifie qu'ANALYZE n'a jamais été effectué, et 1 enregistrement ou plus signifie qu'ANALYZE a été exécuté.

• S'il existe deux enregistrements ou plus, le schema_version des deux enregistrements doit être différent, car les modifications du schéma de la table (telles que ADD COLUMN, CALL SET_TABLE_PROPERTY, etc.) génèrent une nouvelle version, ce qui ajoute un nouvel enregistrement de statistiques. L'enregistrement correspondant à l'ancien schema_version n'est plus utilisé.

• L'exemple de résultat de requête suivant montre que la même table possède 2 enregistrements, et que le schema_version du second enregistrement est inférieur au premier. Le second enregistrement est donc invalide et ne sera pas utilisé ; vous n'avez pas besoin de vous en préoccuper. Hologres ne nettoie pas actuellement les enregistrements historiques expirés dans la table hg_table_statistic, et les utilisateurs n'ont pas à s'inquiéter des anciennes données.

 schema_name | table_name |    user_name     | schema_version | total_rows | sample_rows |  analyze_timestamp  | analyze_count
-------------+------------+------------------+----------------+------------+-------------+---------------------+---------------
 public      | test_fnr   |   BASIC$test_fnr |             13 |        999 |         999 | 2026-03-01 18:05:29 |             2
 public      | test_fnr   |   BASIC$test_fnr |             12 |        999 |         999 | 2026-03-01 08:05:29 |             1
(1 row)

V3.1 et ultérieure :

• Chaque table possède de 0 à 1 enregistrement dans la table hologres_statistic.hg_table_statistic. 0 enregistrement signifie qu'ANALYZE n'a jamais été effectué, et 1 enregistrement signifie qu'ANALYZE a été exécuté.

• Le schema_version est uniformément défini sur -1 (représentant Deprecated).

• Cela signifie que de nombreuses opérations DDL n'invalident plus les statistiques. Par exemple, CALL SET_TABLE_PROPERTY ne redéclenchera pas AUTO ANALYZE, et les statistiques existantes continueront d'être utilisées. Par rapport à Hologres V3.0 et antérieur, la fréquence de déclenchement d'AUTO ANALYZE est considérablement réduite.

1. Requête du nombre de lignes et d'autres statistiques

Les informations sur le nombre de lignes sont enregistrées dans le champ reltuples de la table pg_class.

-- relallvisible > 0: the table has row count statistics
-- relallvisible = 0: the row count is unknown; do not rely on reltuples
-- relallvisible < 0: the table has no statistics
SELECT relallvisible, reltuples FROM pg_class WHERE relname = 'test_table';

1. Requête des statistiques de colonne

En interrogeant la vue pg_stats, vous pouvez obtenir les statistiques pour toutes les colonnes de la table actuelle. Par exemple, pour obtenir les statistiques de la colonne ds de test_table :

select * from pg_stats where tablename = 'test_table' and attname = 'ds';

 schemaname | tablename  | attname | inherited | null_frac | avg_width | n_distinct | most_common_vals | most_common_freqs | histogram_bounds | correlation | most_common_elems | most_common_elem_freqs | elem_count_histogram
------------+------------+---------+-----------+-----------+-----------+------------+------------------+-------------------+------------------+-------------+-------------------+------------------------+----------------------
 public     | test_table | ds      | f         |         0 |         4 |          1 | {20241104}       | {1}               |                  |             |                   |                        |
(1 row)

Consultation des tables dont les statistiques sont manquantes

Hologres fournit la vue HG_STATS_MISSING (le nom réel de la vue peut varier selon la version) pour vérifier les tables de la base de données actuelle dont les statistiques sont manquantes, facilitant ainsi l'identification des objets nécessitant un ANALYZE complémentaire.

Problèmes courants et dépannage

1. Raisons possibles de l'absence d'enregistrements renvoyés par la table hologres_statistic.hg_table_statistic :

• La commande ANALYZE n'a jamais été exécutée (ni manuellement, ni via AUTO ANALYZE) ;

• AUTO ANALYZE ne fonctionne pas ou la table n'a pas rempli les conditions de déclenchement ;

Actions recommandées :

• Commencez par exécuter manuellement la commande suivante :

ANALYZE schema_name.table_name;

• Si la table reste exclue d'AUTO ANALYZE pendant une période prolongée, vérifiez l'état du commutateur AUTO ANALYZE ainsi que la configuration des GUC, ou contactez le support technique.

1. Raisons possibles d'un analyze_timestamp manifestement obsolète :

• AUTO ANALYZE a été désactivé ou restreint (par exemple, autovacuum_enabled = false) ;

• AUTO ANALYZE manque de ressources ou a échoué (à investiguer à l'aide des journaux et de la supervision) ;

Actions recommandées :

• Exécutez ANALYZE une fois manuellement et observez les résultats ;

• Vérifiez les points suivants :

  • L'activation de hg_enable_start_auto_analyze_worker ;

  • Une éventuelle définition erronée de autovacuum_enabled = false ou des restrictions GUC trop strictes ;

  • La présence d'erreurs liées aux tâches AUTO ANALYZE dans le journal des requêtes (Query Log).

1. Estimation anormale du nombre de lignes dans les plans de requête (valeur nettement trop faible ou trop élevée)

• Vérifiez si les statistiques de la table correspondante sont manquantes ou obsolètes ;

• Assurez-vous que les colonnes de prédicat disposent de statistiques (pg_stats) et effectuez un ANALYZE au niveau des colonnes pour les colonnes critiques ;

• Contrôlez si la fonctionnalité d'estimation rapide du nombre de lignes a été désactivée ou n'est pas activée.

1. Statistiques incohérentes entre tables parentes et enfants pour les tables partitionnées, ou absence de statistiques sur la table parente

• Symptôme : La table parente de partition ne contient aucun enregistrement dans hologres_statistic.hg_table_statistic, ou total_rows est nettement inférieur à la somme des nombres de lignes de toutes les tables enfants, ou la distribution MCV des statistiques de la colonne de partition de la table parente est obsolète (par exemple, la distribution de la veille est absente pour la colonne ds dans pg_stats) ;

• Points de dépannage :

  • Vérifiez si l'ANALYZE incrémentiel des partitions ou AUTO ANALYZE a été désactivé ;

SHOW hg_experimental_enable_incremental_analyze;
SHOW hg_experimental_enable_incremental_auto_analyze;

• Utilisez la vue HG_STATS_MISSING pour identifier les tables enfants qui ne peuvent pas être fusionnées ;

• Recherchez d'éventuelles erreurs liées aux tâches AUTO ANALYZE dans le journal des requêtes (Query Log) ;

• Exécutez manuellement ANALYZE child_table; sur les tables enfants dont les statistiques sont manquantes, ou lancez ANALYZE partition_parent_table; sur la table parente pendant les heures creuses afin que le système complète et fusionne les statistiques.

1. Absence de statistiques pour certaines colonnes dans pg_stats

• Symptôme : La colonne existe dans la table, mais ses statistiques correspondantes sont introuvables dans la vue pg_stats.

• Points de dépannage :

  • Vérifiez si les statistiques ont été désactivées via les attributs de colonne (enable_analyze = false ou enable_auto_analyze = false) ;

SELECT attoptions
  FROM pg_attribute
 WHERE attrelid = 'tablename'::regclass::oid
   AND attname = 'columnname';
-[ RECORD 1 ]----------------------
attoptions | {enable_analyze=false}

• Confirmez que la colonne a participé à un ANALYZE (manuel ou AUTO ANALYZE). Si nécessaire, exécutez un ANALYZE au niveau de la colonne : ANALYZE table_name(col_name); ;

SELECT query_id,
       application_name,
       status,
       query_start,
       query
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 hour'
  AND  application_name IN ('Hologres SQL Generated BY ANALYZE', 'Hologres SQL Generated BY AUTO ANALYZE')
  AND  query like '%tablename%'
ORDER BY query_start DESC
LIMIT  2;

• La colonne est-elle d'un type spécial (bytea, jsonb) ?

• Si AUTO ANALYZE a été exécuté sur la table mais qu'aucune colonne ne dispose de statistiques, envisagez une exécution anormale de la tâche AUTO ANALYZE. Par exemple, vérifiez si AUTO ANALYZE a expiré. Comme auto_analyze_work_statement_timeout est défini par défaut sur 1 heure, si la durée de la tâche AUTO ANALYZE dans hologres.hg_query_log est supérieure ou égale à 3 600 000 ms, seules les informations sur le nombre de lignes sont collectées, sans statistiques de colonne.

1. AUTO ANALYZE s'est exécuté, mais le plan de requête ne s'est pas amélioré de manière significative

• Symptôme : Des enregistrements AUTO ANALYZE pour une table spécifique sont visibles dans hologres.hg_query_log, mais le plan de requête réel utilise toujours des estimations de nombre de lignes ou un ordre de jointure manifestement inappropriés ;

• Points de dépannage :

  • Vérifiez si AUTO ANALYZE a expiré. Étant donné que auto_analyze_work_statement_timeout est défini par défaut sur 1 heure, si la durée de la tâche AUTO ANALYZE dans hologres.hg_query_log est supérieure ou égale à 3 600 secondes, seules les informations sur le nombre de lignes sont collectées, sans statistiques de colonne.

  • Recherchez la présence d'indices (Hints), d'ordres de jointure fixes ou d'anciens paramètres GUC au niveau de la session (tels que enable_nestloop, etc.) qui interfèrent avec les choix de l'optimiseur ;

  • Effectuez un ANALYZE manuel sur les tables ou colonnes critiques, puis relancez la requête. Si aucune amélioration n'est constatée, il est recommandé d'approfondir l'investigation à l'aide du journal des requêtes (Query Log), des journaux FE, ou de contacter le support technique.

1. Problèmes de dépassement de mémoire (OOM / limite de mémoire) liés aux statistiques

• Symptôme : Une jointure complexe impliquant plusieurs tables renvoie l'erreur Query executor exceeded total memory limitation ..., ou le plan sélectionne une stratégie de jointure extrêmement inappropriée (par exemple, une boucle imbriquée Nested Loop pilotée par une grande table) ;

• Points de dépannage :

  • Confirmez l'absence de statistiques ou leur obsolescence marquée pour les tables concernées (en croisant les enregistrements de hg_table_statistic et les historiques d'exécution d'AUTO ANALYZE) ;

  • Effectuez un ANALYZE au niveau des colonnes pour les colonnes de jointure et de filtrage. Augmentez la précision d'échantillonnage ou activez la fonctionnalité d'estimation rapide du nombre de lignes si nécessaire ;

  • Si le problème ne survient que dans des scénarios extrêmes de distribution des données ou lors des pics d'activité, consultez le support technique pour évaluer la nécessité d'ajuster le modèle statistique ou certains paramètres GUC (tels que les seuils AUTO ANALYZE, les limites de mémoire, etc.).

ANALYZE manuel et calcul Serverless

• hg_serverless_computing_enable_analyze_statement

  • Description : Contrôle l'exécution des instructions ANALYZE manuelles via des tâches Serverless ;

  • Comportement :

    • Lorsqu'il est défini sur on (valeur par défaut), le système permet de déporter l'exécution des instructions ANALYZE vers les ressources de calcul Serverless, minimisant ainsi l'impact des tâches de statistiques sur l'instance elle-même ;

    • Lorsqu'il est défini sur off, ANALYZE s'exécute sur les ressources locales de l'instance.

  • Recommandations typiques :

    • Dans les instances Serverless, la valeur par défaut est on, ce qui permet de confier exclusivement aux ressources Serverless l'exécution des tâches de statistiques ;

    • Pour le dépannage ou en cas de besoins spécifiques en matière d'utilisation des ressources, vous pouvez temporairement définir ce paramètre sur off afin d'exécuter explicitement ANALYZE sur les ressources locales.

AUTO ANALYZE et calcul Serverless

Lors de la génération des tâches AUTO ANALYZE, le système détermine l'utilisation des ressources Serverless et contrôle le comportement des tâches Serverless selon les paramètres GUC suivants :

• hg_auto_analyze_run_with_serverless_computing

  • Description : Indique si les tâches AUTO ANALYZE doivent s'exécuter via les ressources de calcul Serverless. La valeur par défaut est off pour les instances classiques et on pour les instances Serverless.

  • Comportement :

    • Lorsqu'il est défini sur on, les tâches AUTO ANALYZE envoient les calculs d'échantillonnage au pool de ressources Serverless ;

    • Lorsqu'il est défini sur off, AUTO ANALYZE continue de générer les statistiques via les ressources locales de l'instance.

-- Set at the database level
ALTER DATABASE datname SET hg_auto_analyze_run_with_serverless_computing = on;

• hg_auto_analyze_serverless_computing_query_priority

  • Description : Priorité des tâches AUTO ANALYZE Serverless, comprise entre 1~5. Une valeur plus élevée indique une priorité plus grande. La valeur par défaut est 2 ;

  • Comportement :

    • Lorsque AUTO ANALYZE Serverless est activé, le système définit la priorité correspondante pour chaque tâche de statistiques via SET hg_experimental_serverless_tasks_query_priority = <value>; ;

    • Ce paramètre est utile lorsque le pool de ressources est partagé avec d'autres tâches Serverless (telles que les tâches ETL et les requêtes hors ligne) afin de contrôler la capacité de préemption des tâches de statistiques dans la file d'attente globale ;

  • Recommandations :

    • Dans les environnements de production, conservez généralement une priorité moyenne (comme la valeur par défaut 2 ou augmentez-la modérément à 3) pour éviter de entrer en concurrence avec les travaux métiers essentiels pour l'accès aux ressources ;

    • Pour les scénarios exigeant une actualisation très rapide des statistiques et disposant de ressources Serverless suffisantes, la priorité peut être augmentée de manière appropriée.

• hg_auto_analyze_serverless_computing_enable_persisted_snapshot

  • Description : Indique si les tâches AUTO ANALYZE Serverless doivent utiliser un instantané persistant (persisted snapshot), c'est-à-dire contrôler l'omission d'une opération de vidage (flush) supplémentaire via SET hg_experimental_enable_persisted_snapshot = on/off; ;

  • La valeur par défaut est off pour les instances non Serverless et on pour les instances Serverless.

  • Comportement :

    • Lorsqu'il est défini sur on, les tâches de statistiques tentent de réutiliser l'instantané persistant, réduisant ainsi le besoin de déclencher un vidage. Cette option convient mieux aux statistiques fréquentes ou aux scénarios comportant un grand nombre de tables partitionnées ;

    • Lorsqu'il est défini sur off, les tâches de statistiques utilisent un instantané plus récent, adapté aux scénarios exigeant une cohérence accrue ou une isolation spécifique des versions.

  • Recommandations :

    • N'effectuez aucun ajustement sauf si cela est nécessaire.

Recommandations d'utilisation pour les scénarios de calcul Serverless

1. Privilégiez l'utilisation du calcul Serverless pour gérer les tâches ANALYZE lourdes

   • Lors de l'exécution d'ANALYZE sur des tables ou des tables externes contenant des volumes de données très importants, il est recommandé d'activer :

     • ANALYZE manuel : set hg_computing_resource = 'serverless'; ANALYZE my_table; ;

     • AUTO ANALYZE : ALTER DATABASE mydb SET hg_auto_analyze_run_with_serverless_computing = on; ;

   • Cette approche transfère la charge de calcul des statistiques vers le pool de ressources Serverless, limitant ainsi les interférences avec les requêtes en ligne sur l'instance.

2. Définissez la priorité des tâches AUTO ANALYZE Serverless en fonction de l'importance métier

   • Dans les instances Serverless, pour les bases de données métiers critiques sensibles à l'actualisation des statistiques et dépendant des dernières données statistiques, vous pouvez augmenter de manière appropriée la valeur de hg_auto_analyze_serverless_computing_query_priority ;

   • Dans les instances classiques, l'utilisation des ressources locales pour AUTO ANALYZE est généralement suffisante.

3. Appliquez le principe de l'essai progressif avant d'ajuster les paramètres

   • Les paramètres GUC liés au calcul Serverless constituent également des paramètres avancés. Avant tout ajustement, il est recommandé d'effectuer une validation dans un environnement de test ou de préproduction :

     • Observez la mise en file d'attente et la durée d'exécution des tâches de statistiques dans le pool de ressources Serverless ;

     • Surveillez l'impact sur la latence et l'utilisation des ressources des requêtes métiers essentielles ;

   • Après avoir confirmé l'absence d'effets secondaires majeurs, déployez les modifications en production par base de données ou par étapes.