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.

​

query_plan_aggregation_bucket_top_k

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

​

query_plan_aggregation_in_order

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

​

query_plan_convert_any_join_to_semi_or_anti_join

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

​

query_plan_convert_join_to_in

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).

​

query_plan_convert_outer_join_to_inner_join

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

​

query_plan_direct_read_from_text_index

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.

​

query_plan_display_internal_aliases

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

​

query_plan_enable_multithreading_after_window_functions

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

​

query_plan_enable_optimizations

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)

​

query_plan_execute_functions_after_sorting

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

​

query_plan_filter_push_down

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

​

query_plan_fuse_filter_into_array_join

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.

​

query_plan_join_shard_by_pk_ranges

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.

​

query_plan_join_swap_table

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).

​

query_plan_lift_up_array_join

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

​

query_plan_lift_up_union

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

​

query_plan_lower_array_join_function

Active ou désactive une optimisation au niveau du plan de requête qui transforme une fonction arrayJoin au sein d’une expression en véritable étape ARRAY JOIN, afin qu’elle utilise les mêmes mécanismes d’exécution que la clause ARRAY JOIN (réplication différée et fusion des filtres). Ne prend effet que si le paramètre query_plan_enable_optimizations est défini sur 1.

​

query_plan_max_limit_for_join_lazy_indexing

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.

​

query_plan_max_limit_for_lazy_materialization

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.

​

query_plan_max_limit_for_top_k_optimization

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.

​

query_plan_max_optimizations_to_apply

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.

​

query_plan_max_set_size_for_projection_match

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.

​

query_plan_max_step_description_length

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

​

query_plan_merge_expression_into_join

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

​

query_plan_merge_expressions

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

​

query_plan_merge_filter_into_join_condition

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

​

query_plan_merge_filters

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

​

query_plan_min_columns_for_join_lazy_indexing

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.

​

query_plan_optimize_count_from_text_index

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é.

​

query_plan_optimize_join_order_algorithm

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.

​

query_plan_optimize_join_order_conflict_detector

N’affecte que l’algorithme d’ordre des jointures dpsub. Sélectionne le conflict detector utilisé par DPsub pour déterminer quels réordonnancements des JOIN sont valides. Les valeurs suivantes sont disponibles :

• '' (par défaut) - aucun conflict detector, DPsub applique la restriction de la ON clause par relation
• 'a' - le conflict detector CD-A, qui est correct mais incomplet
• 'c' - le conflict detector CD-C, qui est correct et complet

​

query_plan_optimize_join_order_limit

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.

​

query_plan_optimize_join_order_max_searched_plans

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.

​

query_plan_optimize_join_order_randomize

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.

​

query_plan_optimize_lazy_final

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.

​

query_plan_optimize_lazy_materialization

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

​

query_plan_optimize_lazy_materialization_for_file

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é.

​

query_plan_optimize_lazy_materialization_for_object_storage

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é.

​

query_plan_optimize_prewhere

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

​

query_plan_propagate_predicate_across_join

Active ou désactive une optimisation au niveau du plan de requête qui copie les conjoncts de filtre d’un côté d’une équi-jointure vers l’autre par substitution des clés d’équi-jointure, afin que le pruning par clé primaire/index de l’autre côté puisse en tirer parti. S’applique lorsque le filtre et la lecture MergeTree ne sont séparés de la jointure que par des étapes d’expression et de filtre, et lorsque le conjonct copié compare une colonne de clé primaire à une constante (y compris IN avec un ensemble constant). Un prédicat situé sous une jointure imbriquée ou sous DISTINCT, de même qu’une comparaison entre deux colonnes clés, est laissé tel quel : il ne pourrait pas déclencher de pruning par clé primaire de l’autre côté, et le copier ne ferait donc qu’ajouter du travail inutile. Ne prend effet que si query_plan_enable_optimizations vaut 1.

​

query_plan_push_down_limit

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

​

query_plan_push_down_volume_reducing_functions

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

​

query_plan_push_limit_by_into_sort

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

​

query_plan_read_in_order

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

​

query_plan_read_in_order_through_join

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.

​

query_plan_remove_redundant_distinct

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

​

query_plan_remove_redundant_sorting

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

​

query_plan_remove_unused_columns

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

​

query_plan_reuse_storage_ordering_for_window_functions

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

​

query_plan_short_circuit_constant_false_join

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 aux plans non distribués.

​

query_plan_split_filter

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

​

query_plan_text_index_add_hint

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.

​

query_plan_top_k_through_join

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

​

query_plan_try_use_vector_search

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