paramètres de session query_plan_*

Ces paramètres sont disponibles dans system.settings et sont générés automatiquement à partir du code source.

Active ou désactive une optimisation au niveau du plan de requête qui, lorsqu’une agrégation finale alimente ORDER BY sur les résultats de l’agrégation avec LIMIT n et que le plan prouve que la sélection par compartiment est exacte, matérialise uniquement les n meilleurs groupes de chaque compartiment à deux niveaux, dans cet ordre, lors de la conversion finale de l’agrégation. Le résultat est exact : un groupe ne figurant pas parmi les n meilleurs groupes de son propre compartiment est précédé d’au moins n groupes au niveau global et ne peut donc pas figurer parmi les n meilleurs groupes globaux. Ne prend effet que si le paramètre query_plan_enable_optimizations est défini sur 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive l’optimisation d’agrégation dans l’ordre au niveau du plan de requête. Ne prend effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Permet de convertir ANY JOIN en SEMI ou ANTI JOIN si le filtre après JOIN renvoie toujours false pour les lignes correspondantes ou non correspondantes

Permet de convertir un JOIN en sous-requête avec IN si les colonnes de sortie sont liées uniquement à la table de gauche. Peut produire des résultats incorrects avec des JOIN autres que ANY JOIN (par ex. ALL JOIN, qui est la valeur par défaut).

Permet de convertir OUTER JOIN en INNER JOIN si le filtre appliqué après JOIN exclut toujours les valeurs par défaut

Permet d’effectuer le filtrage de recherche en texte intégral en s’appuyant uniquement sur l’index de texte inversé dans le plan de requête.

Afficher les alias internes (tels que __table1) dans EXPLAIN PLAN au lieu de ceux spécifiés dans la requête d’origine.

Activer le multithreading après l’évaluation des fonctions de fenêtre afin de permettre le traitement parallèle des flux

Active ou désactive l’optimisation des requêtes au niveau du plan de requête.

Valeurs possibles :

• 0 - Désactiver toutes les optimisations au niveau du plan de requête
• 1 - Activer les optimisations au niveau du plan de requête (mais certaines optimisations peuvent toujours être désactivées via leurs paramètres individuels)

Active ou désactive une optimisation au niveau du plan de requête qui déplace les expressions après les étapes de tri. N’a d’effet que si le paramètre query_plan_enable_optimizations est défini sur 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive une optimisation au niveau du plan de requête qui fait descendre les filtres dans le plan d’exécution. N’a d’effet que si le paramètre query_plan_enable_optimizations est défini sur 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive une optimisation au niveau du plan de requête qui fusionne un filtre sur des colonnes d’éléments soumises à ARRAY JOIN dans l’étape ARRAY JOIN. Les tableaux sont ainsi filtrés dans l’espace des éléments avant leur expansion, de sorte que les éléments exclus par le filtre ne sont jamais développés ni répliqués. Ne prend effet que si le paramètre query_plan_enable_optimizations est défini sur 1.

Applique le sharding pour JOIN si les clés de jointure contiennent un préfixe de PRIMARY KEY dans les deux tables. Pris en charge par les algorithmes hash, parallel_hash, full_sorting_merge et parallel_full_sorting_merge. En général, cela n'accélère pas les requêtes, mais peut réduire la consommation de mémoire.

Détermine de quel côté de la jointure doit se trouver la table de build (également appelée table interne, c'est celle qui est insérée dans la table de hachage lors d'un hash join) dans le plan de requête. Ce paramètre est pris en charge uniquement avec la strictness de jointure ALL et la clause JOIN ON. Valeurs possibles :

• 'auto' : laisser le planificateur décider quelle table utiliser comme table de build.
• 'false' : ne jamais permuter les tables (la table de droite est la table de build).
• 'true' : toujours permuter les tables (la table de gauche est la table de build).

Active ou désactive une optimisation au niveau du plan de requête qui remonte les ARRAY JOIN dans le plan d'exécution. Ce paramètre n'a d'effet que si query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive une optimisation au niveau du plan de requête, qui fait remonter des sous-arbres plus importants du plan de requête dans l’union afin de permettre d’autres optimisations. Ne prend effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Contrôle la limite maximale autorisant l’utilisation du plan de requête pour l’optimisation d’indexation paresseuse dans JOIN. Si la valeur est zéro, il n’y a pas de limite.

Contrôle la valeur maximale de LIMIT autorisant l'utilisation du plan de requête pour l'optimisation de la matérialisation différée. Si cette valeur est égale à zéro, il n'y a pas de limite.

Définit la valeur maximale de LIMIT autorisant l’évaluation du plan de requête pour l’optimisation TopK à l’aide de l’index de saut minmax et du filtrage dynamique par seuil. Si elle vaut zéro, aucune limite n’est appliquée.

Ce paramètre contrôle également le comportement de enable_group_by_top_k_optimization.

Limite le nombre total d'optimisations appliquées au plan de requête ; voir le paramètre query_plan_enable_optimizations. Permet d'éviter des temps d'optimisation trop longs pour les requêtes complexes. Dans une requête EXPLAIN PLAN, cesse d'appliquer les optimisations une fois cette limite atteinte et renvoie le plan tel quel. Lors de l'exécution normale des requêtes, si le nombre réel d'optimisations dépasse ce paramètre, une exception est levée.

Nombre maximal de lignes dans un ensemble de clause IN pour lequel le mécanisme de correspondance des projections calcule et compare des hachages de contenu afin de déterminer si deux ensembles sont égaux. Les ensembles plus grands que cette valeur sont considérés comme non correspondants et la projection est ignorée. La valeur zéro désactive entièrement la comparaison par hachage de contenu : une correspondance de projection ne réussit jamais pour les nœuds contenant des ensembles de clause IN.

Utilisé par le mécanisme de correspondance des projections d’agrégation (et par tout futur mécanisme de correspondance des projections devant comparer des ensembles de clause IN). Le calcul du hachage de contenu est en O(N log N) par rapport au nombre d’éléments de l’ensemble ; ce paramètre limite le coût de la planification lorsque de nombreuses clauses IN apparaissent dans la requête ou la projection.

Longueur maximale de la description d’étape dans EXPLAIN PLAN.

Permet de fusionner des expressions avec l’étape JOIN lors de l’optimisation du réordonnancement des jointures.

Active une optimisation au niveau du plan de requête qui fusionne les filtres successifs. N’a d’effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Permet d’intégrer le filtre à la condition JOIN et de convertir CROSS JOIN en INNER.

Permet de fusionner les filtres dans le plan de requête.

Contrôle le nombre minimal de colonnes de charge utile du côté gauche nécessaire pour activer l’optimisation d’indexation paresseuse dans JOIN. 0 signifie que l’optimisation est désactivée.

Permet de répondre à SELECT count() ... WHERE <text search predicate> directement à partir de la cardinalité des listes de publication de l’index de texte, sans matérialiser les lignes correspondantes. Ne prend effet que si query_plan_direct_read_from_text_index est activé.

Spécifie quels algorithmes d’ordre des jointures essayer lors de l’optimisation du plan de requête. Les algorithmes suivants sont disponibles :

• 'greedy' - algorithme glouton de base - est rapide, mais peut ne pas produire le meilleur ordre de jointure
• 'dpsize' - implémente l’algorithme DPsize, actuellement uniquement pour les jointures internes - prend en compte tous les ordres de jointure possibles et trouve le plus optimal, mais peut être lent pour les requêtes comportant de nombreuses tables et de nombreux prédicats de jointure.
• 'dpsub' - implémente l’algorithme DPsub, qui prend en charge à la fois les jointures internes et les jointures autres qu’internes - prend en compte tous les ordres de jointure possibles et trouve le plus optimal, mais peut être lent pour les requêtes comportant de nombreuses tables et de nombreux prédicats de jointure.
• 'dphyp' - implémente l’algorithme DPhyp (Dynamic Programming via Hypergraph Partitioning), actuellement uniquement pour les jointures internes - explore le même espace de recherche que dpsize, mais n’énumère que les paires de sous-graphes connectés, ce qui génère moins de jointures intermédiaires sur des graphes de jointure clairsemés, au prix de ne pas prendre en compte les produits cartésiens Plusieurs algorithmes peuvent être spécifiés sous forme de liste séparée par des virgules, par exemple dphyp,greedy. Ils sont essayés dans l’ordre ; si un algorithme ne peut pas traiter la requête (par exemple, en raison de jointures externes ou de composantes non connexes), le suivant est utilisé comme solution de repli.

Optimise l'ordre des jointures au sein d'une même sous-requête. Cette fonctionnalité n'est actuellement prise en charge que dans des cas très limités. La valeur correspond au nombre maximal de tables à optimiser.

Nombre maximal de plans partiels que l'optimiseur de l'ordre des jointures peut énumérer avant d'abandonner et de basculer vers l'algorithme suivant dans query_plan_optimize_join_order_algorithm. Cette limite borne de manière déterministe le temps d'optimisation (indépendamment du temps écoulé) sur des graphes de jointures denses, tels que des cliques ou des étoiles, où l'espace de recherche croît exponentiellement. Définissez cette valeur sur 0 pour désactiver la limite. Cela n'a aucun effet sur la valeur par défaut query_plan_optimize_join_order_limit, pour laquelle la recherche reste toujours bien en deçà de cette limite.

Lorsqu’il est différent de zéro, l’optimiseur de l’ordre des jointures utilise des cardinalités et des NDV générées aléatoirement au lieu de statistiques réelles. Lorsqu’il est défini sur 1, une graine aléatoire est générée ; lorsqu’il est défini sur une valeur > 1, cette valeur est utilisée directement comme graine. Ce paramètre est destiné aux tests afin de détecter les erreurs causées par différents ordres de jointure.

Optimise la lecture avec FINAL à partir de ReplacingMergeTree en construisant un ensemble de clés primaires, puis en l’utilisant pour l’analyse d’index.

Utiliser le plan de requête pour l’optimisation par matérialisation différée.

Utilise l'optimisation de matérialisation différée lors de la lecture de fichiers Parquet locaux avec la fonction de table file et le moteur de table File : pour les requêtes ORDER BY ... LIMIT n, les colonnes non nécessaires au tri et au filtrage ne sont lues que pour les n lignes conservées après l'application de LIMIT. Ne prend effet que si query_plan_optimize_lazy_materialization est activé.

Utilise l'optimisation de matérialisation différée pour lire des fichiers Parquet depuis le stockage d'objets, y compris les tables Iceberg : pour les requêtes ORDER BY ... LIMIT n, les colonnes inutiles pour le tri et le filtrage ne sont lues que pour les n lignes conservées après application de LIMIT. Ne prend effet que si query_plan_optimize_lazy_materialization est activé.

Permet de pousser le filtre dans l'expression PREWHERE pour les moteurs de stockage pris en charge

Active une optimisation au niveau du plan de requête qui pousse les LIMIT vers le bas dans le plan d'exécution. N'a d'effet que si le paramètre query_plan_enable_optimizations est défini sur 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive une optimisation au niveau du plan de requête qui déplace les fonctions réduisant le volume (length, lengthUTF8, empty, notEmpty) vers le bas du plan d’exécution, après les étapes Sorting et Filter. Le résultat de taille fixe remplace l’argument String / FixedString de grande taille, de sorte que celui-ci n’est plus transmis à travers ces étapes. Cette réécriture n’est appliquée que si la colonne d’argument n’est pas nécessaire en amont de l’étape après laquelle elle est déplacée.

Ne prend effet que si le paramètre query_plan_enable_optimizations est égal à 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive une optimisation au niveau du plan de requête pour les requêtes ORDER BY ... LIMIT BY. Lorsque les colonnes de LIMIT BY sont un préfixe de la clause ORDER BY, chaque flux trié en parallèle applique LIMIT BY avant que les flux ne soient fusionnés en un seul, ce qui réduit le nombre de lignes traitées par la fusion finale et les étapes suivantes du pipeline. Accélère les requêtes dans lesquelles LIMIT BY écarte une grande partie des lignes.

Ne prend effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive l’optimisation de lecture ordonnée au niveau du plan de requête. Ne prend effet que si le paramètre query_plan_enable_optimizations est défini sur 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Conserve la lecture dans l’ordre depuis la table de gauche lors des opérations JOIN, afin qu’elle puisse être utilisée par les étapes suivantes.

Active ou désactive une optimisation du plan de requête qui supprime les étapes DISTINCT redondantes. N’a d’effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive une optimisation au niveau du plan de requête qui supprime les étapes de tri redondantes, par exemple dans les sous-requêtes. Ne prend effet que si le paramètre query_plan_enable_optimizations est défini sur 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive une optimisation au niveau du plan de requête de la requête, qui tente de supprimer les colonnes inutilisées (à l’entrée comme à la sortie) des étapes du plan. N’a d’effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Aliases : optimize_read_in_window_order

Active ou désactive une optimisation au niveau du plan de requête qui exploite l'ordre de tri du stockage lors du tri pour les fonctions de fenêtre. Ne prend effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Court-circuite un JOIN dont la condition ON est réduite à une constante false en remplaçant par une source vide chaque côté d'entrée qui ne peut contribuer aucune ligne (les deux côtés pour INNER/CROSS/SEMI, le côté non préservé pour LEFT/RIGHT), afin de ne pas lire le côté qui ne contribue pas au résultat. S'applique à l'analyseur (enable_analyzer = 1) et aux plans non distribués.

Active ou désactive une optimisation au niveau du plan de requête qui décompose les filtres en expressions. N’a d’effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Permet d'ajouter un hint (prédicat supplémentaire) pour le filtrage généré à partir de l'index de texte inversé dans le plan de requête.

Active ou désactive une optimisation au niveau du plan de requête qui propage ORDER BY ... LIMIT n à travers une jointure lorsque la clé de tri ne référence que des colonnes du côté préservé par la jointure (LEFT/RIGHT). Elle limite le nombre de lignes que l’entrée du côté préservé doit produire avant la jointure. Ne prend effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

Active ou désactive une optimisation au niveau du plan de requête visant à utiliser l'index de similarité vectorielle. Ne prend effet que si le paramètre query_plan_enable_optimizations vaut 1.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer