Remarques d'utilisation et scénarios d'application des hints - Hologres

Les hints vous permettent de remplacer les décisions de l'optimiseur de requêtes de Hologres — ordre des jointures, méthode de jointure, distribution des données et paramètres GUC — sans modifier la logique de la requête. Utilisez les hints lorsque l'optimiseur génère un plan d'exécution sous-optimal en raison de statistiques obsolètes ou d'une distribution inhabituelle des données.

Les hints sont pris en charge dans Hologres V2.2 et versions ultérieures. Si votre instance exécute une version V2.1 ou antérieure, mettez-la à niveau avant d'utiliser les hints.

Prérequis

Avant de commencer, assurez-vous que :

Vous disposez d'une instance Hologres exécutant la version V2.2 ou ultérieure.
Le paramètre GUC pg_hint_plan_enable_hint est défini sur on.

Activez les hints au niveau de la session :

SET pg_hint_plan_enable_hint=on;

Ou activez les hints au niveau de la base de données (la modification prend effet pour les nouvelles connexions) :

ALTER DATABASE <dbname> SET pg_hint_plan_enable_hint=on;

Syntaxe des hints

Placez un hint immédiatement après le mot-clé DML (SELECT, INSERT, UPDATE ou DELETE) :

SELECT|UPDATE|INSERT|DELETE /*+HINT <HintName(params)> */ ...

Règles principales :

Encadrez les hints entre /*+HINT et */.
Les mots-clés des hints ne sont pas sensibles à la casse.
Un seul bloc de hint peut contenir plusieurs mots-clés de hint.
Les commentaires ne sont pas autorisés à l'intérieur d'un bloc de hint.
Si une instruction SELECT comporte plusieurs blocs de hints consécutifs, seul le premier est pris en compte.

Mots-clés des hints

Le tableau suivant répertorie tous les mots-clés de hint pris en charge.

Type	Mot-clé	Description	Version
Méthode de jointure	`HashJoin(table1 table2[ table...])`	Force une jointure par hachage.	V2.2+
	`NestLoop(table1 table2[ table...])`	Force une jointure par boucles imbriquées.	V2.2+
Ordre des jointures	`Leading(table1 table2[ table...])`	Force un ordre de jointure (arbre gauche-profond par défaut).	V2.2+
	`Leading(<join pair>)`	Force un ordre et une direction de jointure. Utilisez les parenthèses `()` pour spécifier explicitement les paires de jointure.	V2.2+
Filtre d'exécution	`RuntimeFilter(table1 table2[ table...])`	Force un filtre d'exécution pour les jointures par hachage sur les tables spécifiées.	V2.2+
GUC	`Set(GUC-parameter value)`	Définit la valeur d'un paramètre GUC pour la durée de la requête actuelle. Consultez les paramètres GUC.	V2.2+
Motion	`Broadcast(table[ table...])`	Force la diffusion (broadcast) de la table spécifiée lors d'une opération JOIN. À utiliser conjointement avec `Leading` dans la plupart des cas.	V3.0+
	`NoBroadcast(table[ table...])`	Empêche la diffusion de la table spécifiée.	V3.0+
	`Gather(table[ table...])`	Force le regroupement (gather) de la table spécifiée lors d'une opération JOIN.	V2.2+
	`NoGather(table[ table...])`	Empêche le regroupement de la table spécifiée.	V2.2+

Exemples :

-- HashJoin
SELECT
    /*+HINT HashJoin(table1 table2 table3) */
    table1.a
FROM
    table1
    JOIN table2 ON table1.a = table2.a
    JOIN table3 ON table1.a = table3.a;

-- NestLoop
SELECT /*+HINT NestLoop(table1 table2) */ * FROM table1 JOIN table2 ON table1.a = table2.a;

-- Leading (left-deep: join table2 and table1 first, then table3)
SELECT /*+HINT Leading(table2 table1) */ table1.a FROM table1 JOIN table2 ON table1.a = table2.a;

-- Leading with join pairs (parentheses control tree shape)
-- This joins (table2 JOIN table1) and (table3 JOIN table4) independently, then joins the two results.
SELECT
/*+HINT Leading((table2 table1) (table3 table4)) */
    *
FROM
    table1
    LEFT JOIN table2 ON table1.a = table2.a
    RIGHT JOIN table3 ON table1.a = table3.a
    LEFT JOIN table4 ON table3.a = table4.a
ORDER BY
    table1.a;

-- RuntimeFilter
SELECT /*+HINT RuntimeFilter(table1 table2) */ * FROM table1 JOIN table2 ON table1.a = table2.a;

-- GUC: disable count distinct reuse for this query only
EXPLAIN
SELECT
    /*+HINT set(hg_experimental_enable_reuse_cte_of_count_distinct off) */
    count(DISTINCT a),
    count(DISTINCT b)
FROM table1;

Remarques d'utilisation

Objets pris en charge

Les hints s'appliquent aux tables standard (y compris les tables étrangères), aux sous-requêtes et aux expressions de table communes (CTE). Les vues ne sont pas prises en charge.

Portée des hints

Un hint s'applique uniquement au niveau de la requête où il est placé. Un hint situé dans une requête parente ne peut pas référencer des tables présentes dans une sous-requête, et inversement. Dans l'exemple suivant, Leading(tt t2) ne peut référencer que tt et t2 ; Leading(t t1) ne peut référencer que t et t1.

SELECT /*+HINT Leading(t t1) */ * FROM t1 JOIN (
  SELECT /*+HINT Leading(tt t2) */ * FROM t2 JOIN (
    SELECT * FROM t3
  ) tt
) t;

Exception — hints GUC : Un hint GUC s'applique à l'ensemble de la requête, même s'il est placé dans une sous-requête. Les requêtes suivantes ne sont pas affectées.

-- The GUC hint in the subquery applies to the entire outer query.
SELECT
    count(DISTINCT a),
    count(DISTINCT b)
FROM (
    SELECT
        /*+HINT set(hg_experimental_enable_reuse_cte_of_count_distinct off) */
        t1.a, t2.b
    FROM
        t1
        JOIN t2 ON t1.a = t2.a)

Hint Leading : contrôle de la forme de l'arbre de jointure

Sans parenthèses, Leading construit un arbre gauche-profond : Leading(t1 t2 t3) joint d'abord t1 et t2, puis le résultat avec t3.

Utilisez des parenthèses pour contrôler explicitement la forme de l'arbre :

Syntaxe	Forme de l'arbre	Ordre de jointure
`Leading(t1 t2 t3)`	Gauche-profond	(t1 ⋈ t2) ⋈ t3
`Leading(t1 (t2 t3))`	Droite-profond	t1 ⋈ (t2 ⋈ t3)

Les parenthèses imbriquées sont prises en charge.

Résolution des conflits

Lorsque des hints du même type entrent en conflit, seul le premier hint est pris en compte. Des conflits surviennent lorsque :

Deux hints spécifient les mêmes tables.
Deux hints spécifient des ensembles de tables identiques.
Les tables d'un hint d'ordre de jointure constituent un sous-ensemble des tables d'un autre hint.
Les ensembles de tables de deux hints de méthode de jointure, de filtre d'exécution ou de jointure asymétrique ne sont pas des sous-ensembles l'un de l'autre.

Exemples :

-- HashJoin(t1 t2) and NestLoop(t2 t1) conflict (same tables). Only HashJoin(t1 t2) is applied.
SELECT /*+HINT HashJoin(t1 t2) NestLoop(t2 t1) */ ...

-- Leading(t1 t2) is a subset of Leading(t1 t2 t3). Only Leading(t1 t2) is applied.
SELECT /*+HINT Leading(t1 t2) Leading(t1 t2 t3) */ ...

Hints de méthode de jointure et de filtre d'exécution

Au moins deux paramètres valides sont requis. Les paramètres valides sont des tables, des sous-requêtes ou des CTE au niveau de la requête où le hint s'applique. Par exemple, Leading(t1 t1) ne possède qu'un seul paramètre valide.
Si le plan candidat généré n'inclut pas la jointure spécifiée par un hint de méthode de jointure, le hint n'a aucun effet. Par exemple, HashJoin(t1 t2) n'a aucun effet si le plan joint d'abord t1 avec t3, puis t2. Dans ce cas, ajoutez Leading(t1 t2) pour forcer l'ordre de jointure.
Les hints de filtre d'exécution ne s'appliquent qu'aux jointures par hachage.

INSERT INTO ... SELECT

Le hint INSERT s'applique à la table de destination et à la table source de l'instruction SELECT la plus externe. Vous ne pouvez pas spécifier de hints simultanément dans les clauses INSERT et SELECT :

-- Correct: hint on INSERT
INSERT /*+HINT Leading(target (t1 t2)) */ INTO target SELECT t1.a, t2.b FROM t1 JOIN t2 ON t1.a=t2.a;

-- Correct: hint on SELECT
INSERT INTO target SELECT /*+HINT Leading(t2 t1) */ t1.a, t2.b FROM t1 JOIN t2 ON t1.a=t2.a;

-- Incorrect: hints on both INSERT and SELECT — results in an error
INSERT /*+HINT Leading(target (t1 t2)) */ INTO target SELECT /*+HINT Leading(t2 t1) */ t1.a, t2.b FROM t1 JOIN t2 ON t1.a=t2.a;
-- ERROR: insert statement with hint should not have sub select with hint at the same time

Scénarios

Les exemples suivants utilisent ces tables :

CREATE TABLE target (a int primary key, b int);
CREATE TABLE t1 (a int, b int);
CREATE TABLE t2 (a int, b int);
CREATE TABLE t3 (a int);
CREATE TABLE t4 (a int);

Ajuster l'ordre des jointures

Des statistiques obsolètes constituent la cause la plus fréquente d'un ordre de jointure sous-optimal. Cela se produit lorsque l'instruction ANALYZE n'a pas été exécutée récemment, ou lorsque le nombre réel de lignes après un filtre ou une jointure diffère considérablement de l'estimation. Consultez ANALYZE et AUTO ANALYZE.

Dans une jointure par hachage, Hologres utilise la table la plus petite pour construire la table de hachage (affichée en bas de l'opérateur Hash dans le plan d'exécution). Si t2 contient plus de lignes que t1 mais que l'optimiseur choisit t1 comme côté de construction, utilisez un hint Leading pour inverser l'ordre de jointure.

SELECT /*+HINT Leading(t2 t1) */ t1.a FROM t1 JOIN t2 ON t1.a = t2.a;

Plan d'exécution sans hint :

QUERY PLAN
-----------------------------------------------------------------------------------
 Gather  (cost=0.00..10.07 rows=1000 width=4)
   ->  Hash Join  (cost=0.00..10.05 rows=1000 width=4)
         Hash Cond: (t1.a = t2.a)
         ->  Redistribution  (cost=0.00..5.01 rows=1000 width=4)
               Hash Key: t1.a
               ->  Local Gather  (cost=0.00..5.00 rows=1000 width=4)
                     ->  Seq Scan on t1  (cost=0.00..5.00 rows=1000 width=4)
         ->  Hash  (cost=5.01..5.01 rows=1000 width=4)
               ->  Redistribution  (cost=0.00..5.01 rows=1000 width=4)
                     Hash Key: t2.a
                     ->  Local Gather  (cost=0.00..5.00 rows=1000 width=4)
                           ->  Seq Scan on t2  (cost=0.00..5.00 rows=1000 width=4)

Plan d'exécution avec hint :

QUERY PLAN
-----------------------------------------------------------------------------------
 Gather  (cost=0.00..10.07 rows=1000 width=4)
   ->  Hash Join  (cost=0.00..10.05 rows=1000 width=4)
         Hash Cond: (t2.a = t1.a)
         ->  Redistribution  (cost=0.00..5.01 rows=1000 width=4)
               Hash Key: t2.a
               ->  Local Gather  (cost=0.00..5.00 rows=1000 width=4)
                     ->  Seq Scan on t2  (cost=0.00..5.00 rows=1000 width=4)
         ->  Hash  (cost=5.01..5.01 rows=1000 width=4)
               ->  Redistribution  (cost=0.00..5.01 rows=1000 width=4)
                     Hash Key: t1.a
                     ->  Local Gather  (cost=0.00..5.00 rows=1000 width=4)
                           ->  Seq Scan on t1  (cost=0.00..5.00 rows=1000 width=4)

t2 construit désormais la table de hachage, ce qui correspond au comportement attendu lorsque t2 est la table la plus petite.

Appliquer un hint GUC

Les hints GUC configurent un paramètre GUC pour une seule requête. Le paramètre revient à sa valeur initiale une fois la requête terminée et n'affecte pas les autres requêtes.

SELECT /*+HINT set(hg_experimental_query_batch_size 512) */ t1.a FROM t1 JOIN t2 ON t1.a = t2.a;

Plan d'exécution :

QUERY PLAN
Hash Join  (cost=0.00..10.00 rows=1 width=4)
  Hash Cond: (t1.a = t2.a)
  ->  Gather  (cost=0.00..5.00 rows=1 width=4)
        ->  Local Gather  (cost=0.00..5.00 rows=1 width=4)
              ->  Seq Scan on t1  (cost=0.00..5.00 rows=1 width=4)
  ->  Hash  (cost=5.00..5.00 rows=1 width=4)
        ->  Gather  (cost=0.00..5.00 rows=1 width=4)
              ->  Local Gather  (cost=0.00..5.00 rows=1 width=4)
                    ->  Seq Scan on t2  (cost=0.00..5.00 rows=1 width=4)

Utiliser des hints dans les CTE et les sous-requêtes

Les hints présents dans les CTE et les sous-requêtes contrôlent chacun la stratégie de jointure à leur propre niveau de requête. L'exemple suivant applique plusieurs hints à différents niveaux de requête.

WITH c1 AS (
        SELECT /*+HINT Leading(t2 t1) */ t1.a FROM (
            (
                SELECT /*+HINT leading(t2 t1) */ t1.a FROM t1 JOIN t2 ON t1.a = t2.a
            ) AS t1
            JOIN
            (
                SELECT /*+HINT NestLoop(t4 t3) */ t4.a FROM t3 JOIN t4 ON t3.a = t4.a
            ) AS t2
            ON t1.a = t2.a
        )
    ),
    c2 AS (
        SELECT /*+HINT leading(t1 t2) */ t2.a FROM (
            (
                SELECT /*+HINT Leading(t1 t2) */ t1.a FROM t1 JOIN t2 ON t1.a = t2.a
            ) AS t1
            JOIN
            (
                SELECT /*+HINT Leading(t4 t3) */ t4.a FROM t3 JOIN t4 ON t3.a = t4.a
            ) AS t2
            ON t1.a = t2.a
        )
    )
    SELECT /*+HINT NestLoop(v2 v1) */  * FROM (
        (
            SELECT /*+HINT Leading (c1 t2) */ c1.a FROM c1 JOIN t2 ON c1.a = t2.a
        ) AS v1
        JOIN
        (
            SELECT /*+HINT Leading (t1 c2) */ c2.a FROM t1 JOIN c2 ON t1.a = c2.a
        ) AS v2
        ON v1.a = v2.a
    )
    ORDER BY v2.a;

Utiliser des hints dans les instructions INSERT

Utilisez les hints INSERT lorsque la table de destination participe à une jointure avec les tables sources et que l'ordre de jointure par défaut est sous-optimal.

Exemple 1 : Hint sur la clause INSERT

Le hint s'applique à la table de destination et à la table source de l'instruction SELECT la plus externe. Utilisez cette approche lorsque le résultat de t1 JOIN t2 est petit, mais que la table de destination target est volumineuse.

INSERT /*+HINT Leading(target (t1 t2)) */ INTO target SELECT t1.a, t2.b FROM t1 JOIN t2 ON t1.a=t2.a;

Plan d'exécution :

QUERY PLAN
-----------------------------------------------------------------------------------------------------------------
 Gather  (cost=0.00..26.57 rows=1000 width=8)
   ->  Insert  (cost=0.00..26.54 rows=1000 width=8)
         ->  Project  (cost=0.00..16.12 rows=1000 width=8)
               ->  Hash Right Join  (cost=0.00..15.12 rows=1000 width=12)
                     Hash Cond: (target.a = t1.a)
                     ->  Local Gather  (cost=0.00..5.00 rows=1000 width=4)
                           ->  Seq Scan on target  (cost=0.00..5.00 rows=1000 width=4)
                     ->  Hash  (cost=10.07..10.07 rows=1000 width=8)
                           ->  Redistribution  (cost=0.00..10.07 rows=1000 width=8)
                                 Hash Key: t1.a
                                 ->  Hash Join  (cost=0.00..10.06 rows=1000 width=8)
                                       Hash Cond: (t1.a = t2.a)
                                       ->  Redistribution  (cost=0.00..5.01 rows=1000 width=4)
                                             Hash Key: t1.a
                                             ->  Local Gather  (cost=0.00..5.00 rows=1000 width=4)
                                                   ->  Seq Scan on t1  (cost=0.00..5.00 rows=1000 width=4)
                                       ->  Hash  (cost=5.01..5.01 rows=1000 width=8)
                                             ->  Redistribution  (cost=0.00..5.01 rows=1000 width=8)
                                                   Hash Key: t2.a
                                                   ->  Local Gather  (cost=0.00..5.00 rows=1000 width=8)
                                                         ->  Seq Scan on t2  (cost=0.00..5.00 rows=1000 width=8)

Exemple 2 : Hint sur la clause SELECT

Les deux instructions suivantes produisent le même effet :

INSERT INTO target SELECT /*+HINT Leading(t2 t1) */ t1.a, t2.b FROM t1 JOIN t2 ON t1.a=t2.a;

INSERT /*+HINT Leading(t2 t1) */ INTO target SELECT t1.a, t2.b FROM t1 JOIN t2 ON t1.a=t2.a;

Utiliser des hints dans les instructions UPDATE

Utilisez les hints UPDATE lorsque la table de destination effectue une jointure avec une table source et que vous devez contrôler l'ordre de jointure.

Dans l'exemple suivant, t1 contient plus de lignes que target. Le hint fait de target le côté de construction de la jointure par hachage.

UPDATE /*+HINT Leading(t1 target) */ target SET b=t1.b+1 FROM t1 WHERE t1.a=target.a;

Plan d'exécution sans hint :

QUERY PLAN
-----------------------------------------------------------------------------------------------
 Gather  (cost=0.00..52.77 rows=1000 width=1)
   ->  Update  (cost=0.00..52.76 rows=1000 width=1)
         ->  Project  (cost=0.00..11.09 rows=1000 width=32)
               ->  Hash Join  (cost=0.00..10.08 rows=1000 width=32)
                     Hash Cond: (target.a = t1.a)
                     ->  Local Gather  (cost=0.00..5.00 rows=1000 width=28)
                           ->  Seq Scan on target  (cost=0.00..5.00 rows=1000 width=28)
                     ->  Hash  (cost=5.01..5.01 rows=1000 width=8)
                           ->  Redistribution  (cost=0.00..5.01 rows=1000 width=8)
                                 Hash Key: t1.a
                                 ->  Local Gather  (cost=0.00..5.00 rows=1000 width=8)
                                       ->  Seq Scan on t1  (cost=0.00..5.00 rows=1000 width=8)

Plan d'exécution avec hint :

QUERY PLAN
----------------------------------------------------------------------------------------------
 Gather  (cost=0.00..52.77 rows=1000 width=1)
   ->  Update  (cost=0.00..52.76 rows=1000 width=1)
         ->  Project  (cost=0.00..11.09 rows=1000 width=32)
               ->  Hash Join  (cost=0.00..10.08 rows=1000 width=32)
                     Hash Cond: (t1.a = target.a)
                     ->  Redistribution  (cost=0.00..5.01 rows=1000 width=8)
                           Hash Key: t1.a
                           ->  Local Gather  (cost=0.00..5.00 rows=1000 width=8)
                                 ->  Seq Scan on t1  (cost=0.00..5.00 rows=1000 width=8)
                     ->  Hash  (cost=5.00..5.00 rows=1000 width=28)
                           ->  Local Gather  (cost=0.00..5.00 rows=1000 width=28)
                                 ->  Seq Scan on target  (cost=0.00..5.00 rows=1000 width=28)

target construit désormais la table de hachage, ce qui réduit le coût de la jointure.

Utiliser des hints de filtre d'exécution

Hologres prend en charge les filtres d'exécution pour les jointures par hachage. Si une requête ne remplit pas les conditions nécessaires au déclenchement automatique d'un filtre d'exécution, utilisez un hint RuntimeFilter pour en forcer l'application.

Important

Forcer l'application d'un filtre d'exécution n'améliore pas systématiquement les performances. Vérifiez le plan d'exécution avant d'appliquer ce hint en production.

SELECT /*+HINT runtimefilter(t1 t2) */ * FROM t1 JOIN t2 ON t1.a = t2.a;

Plan d'exécution (la ligne Runtime Filter Cond confirme que le filtre est actif) :

QUERY PLAN
-----------------------------------------------------------------------------------
 Gather  (cost=0.00..10.13 rows=1000 width=16)
   ->  Hash Join  (cost=0.00..10.07 rows=1000 width=16)
         Hash Cond: (t1.a = t2.a)
         Runtime Filter Cond: (t1.a = t2.a)
         ->  Redistribution  (cost=0.00..5.01 rows=1000 width=8)
               Hash Key: t1.a
               ->  Local Gather  (cost=0.00..5.00 rows=1000 width=8)
                     ->  Seq Scan on t1  (cost=0.00..5.00 rows=1000 width=8)
                           Runtime Filter Target Expr: t1.a
         ->  Hash  (cost=5.01..5.01 rows=1000 width=8)
               ->  Redistribution  (cost=0.00..5.01 rows=1000 width=8)
                     Hash Key: t2.a
                     ->  Local Gather  (cost=0.00..5.00 rows=1000 width=8)
                           ->  Seq Scan on t2  (cost=0.00..5.00 rows=1000 width=8)

Utiliser des hints de motion

Les hints de motion contrôlent la manière dont Hologres distribue les données entre les workers lors d'une opération JOIN, soit en diffusant (broadcasting) une table à tous les workers, soit en la redistribuant (shuffling).

Exemple 1 : Forcer la diffusion

Utilisez Broadcast lorsque les statistiques sont inexactes et que l'optimiseur redistribue incorrectement une grande quantité de données. Étant donné qu'une jointure par hachage ne peut diffuser que depuis le côté de construction, associez Broadcast à Leading pour spécifier l'ordre de jointure correct.

SELECT /*+HINT Leading(t2 t1) Broadcast(t1) */ * FROM t1 JOIN t2 ON t1.a = t2.a;

Plan d'exécution :

QUERY PLAN
----------------------------------------------------------------------------------------------
  Gather  (cost=0.00..100000000000000005366162204393472.00 rows=1000 width=16)
   ->  Hash Join  (cost=0.00..100000000000000005366162204393472.00 rows=1000 width=16)
         Hash Cond: (t2.a = t1.a)
         ->  Local Gather  (cost=0.00..5.00 rows=1000 width=8)
               ->  Seq Scan on t2  (cost=0.00..5.00 rows=1000 width=8)
         ->  Hash  (cost=100000000000000005366162204393472.00..100000000000000005366162204393472.00 rows=3000 width=8)
               ->  Broadcast  (cost=0.00..100000000000000005366162204393472.00 rows=3000 width=8)
                     ->  Local Gather  (cost=0.00..5.00 rows=1000 width=8)
                           ->  Seq Scan on t1  (cost=0.00..5.00 rows=1000 width=8)

Exemple 2 : Désactiver la diffusion

Utilisez NoBroadcast lorsque l'optimiseur sous-estime le nombre réel de lignes d'une table et tente de diffuser une table volumineuse, ce qui entraîne des performances très médiocres. Ce hint nécessite Hologres V3.0 ou une version ultérieure.

Commencez par créer les tables de test :

Données d'exemple

CREATE TABLE test1(a int, b int);
CREATE TABLE test2(a int, b int);

INSERT INTO test1 SELECT 1, i FROM generate_series(1, 10) AS i;
INSERT INTO test2 SELECT 1, i FROM generate_series(1, 1000000) AS i;

ANALYZE test1, test2;

Instructions SQL d'exemple

Sans le hint, l'optimiseur diffuse test1 (estimée à 200 lignes après mise à jour des statistiques, mais contenant réellement seulement 10 lignes) :
Effectuer une diffusion sans utiliser de hint
```
EXPLAIN SELECT * FROM test1 JOIN test2 ON test1.b = test2.b;
```
Utiliser un hint pour désactiver la diffusion
```
EXPLAIN SELECT /*+HINT NoBroadcast(test1) */ * FROM test1 JOIN test2 ON test1.b = test2.b;
```

Plan d'exécution :

Avec NoBroadcast, Hologres redistribue les deux tables à la place :

Effectuer une diffusion sans utiliser de hint

QUERY PLAN
---------------------------------------------------------------------------------
Gather  (cost=0.00..51.98 rows=1000000 width=16)
  ->  Hash Join  (cost=0.00..13.12 rows=1000000 width=16)
        Hash Cond: (test2.b = test1.b)
        ->  Local Gather  (cost=0.00..5.23 rows=1000000 width=8)
              ->  Seq Scan on test2  (cost=0.00..5.20 rows=1000000 width=8)
        ->  Hash  (cost=5.00..5.00 rows=200 width=8)
              ->  Broadcast  (cost=0.00..5.00 rows=200 width=8)
                    ->  Local Gather  (cost=0.00..5.00 rows=10 width=8)
                          ->  Seq Scan on test1  (cost=0.00..5.00 rows=10 width=8)

Utiliser un hint pour désactiver la diffusion

QUERY PLAN
---------------------------------------------------------------------------------
Gather  (cost=0.00..53.23 rows=1000000 width=16)
  ->  Hash Join  (cost=0.00..14.37 rows=1000000 width=16)
        Hash Cond: (test2.b = test1.b)
        ->  Redistribution  (cost=0.00..6.48 rows=1000000 width=8)
              Hash Key: test2.b
              ->  Local Gather  (cost=0.00..5.23 rows=1000000 width=8)
                    ->  Seq Scan on test2  (cost=0.00..5.20 rows=1000000 width=8)
        ->  Hash  (cost=5.00..5.00 rows=10 width=8)
              ->  Redistribution  (cost=0.00..5.00 rows=10 width=8)
                    Hash Key: test1.b
                    ->  Local Gather  (cost=0.00..5.00 rows=10 width=8)
                          ->  Seq Scan on test1  (cost=0.00..5.00 rows=10 width=8)

Vérifier que les hints sont pris en compte

Exécutez EXPLAIN avant et après l'ajout d'un hint. Confirmez que la modification du plan d'exécution correspond à votre intention — par exemple, l'ordre de Hash Cond change lorsque vous inversez l'ordre de jointure avec Leading, ou Runtime Filter Cond apparaît lorsque vous appliquez RuntimeFilter.

Si le plan ne change pas, vérifiez les points suivants :

Hint non appliqué en raison d'un conflit : Lorsque des hints du même type entrent en conflit, seul le premier est analysé. Supprimez les hints dupliqués ou conflictuels.
Paramètres de hint invalides : Les hints de méthode de jointure et d'ordre de jointure nécessitent au moins deux paramètres valides (tables, sous-requêtes ou CTE au même niveau de requête). Leading(t1 t1) ne possède qu'un seul paramètre valide et ne sera pas pris en compte.
Plan incompatible avec le hint : Si la combinaison spécifiée est impossible (par exemple, NestLoop avec une RIGHT JOIN sur certaines configurations de table), Hologres renvoie l'erreur suivante : ERROR: ORCA failed to produce a plan : No plan has been computed for required properties. Révisez la combinaison de hints et ajustez-la en conséquence.

Hologres:HINT

Prérequis

Syntaxe des hints

Mots-clés des hints

Remarques d'utilisation

Objets pris en charge

Portée des hints

Hint Leading : contrôle de la forme de l'arbre de jointure

Résolution des conflits

Hints de méthode de jointure et de filtre d'exécution

INSERT INTO ... SELECT

Scénarios

Ajuster l'ordre des jointures

Appliquer un hint GUC

Utiliser des hints dans les CTE et les sous-requêtes

Utiliser des hints dans les instructions INSERT

Utiliser des hints dans les instructions UPDATE

Utiliser des hints de filtre d'exécution

Utiliser des hints de motion

Effectuer une diffusion sans utiliser de hint

Utiliser un hint pour désactiver la diffusion

Effectuer une diffusion sans utiliser de hint

Utiliser un hint pour désactiver la diffusion

Vérifier que les hints sont pris en compte

Étapes suivantes