paramètres de session join_*

Ces paramètres sont disponibles dans system.settings et sont générés automatiquement à partir du code source. Spécifie quel algorithme de JOIN est utilisé. Plusieurs algorithmes peuvent être spécifiés, et un algorithme disponible est choisi pour une requête donnée en fonction du type, de la strictness et du moteur de table. La plupart des algorithmes n’affectent une requête que lorsqu’ils sont sélectionnés pour celle-ci. Certains, cependant, modifient la planification du simple fait d’être répertoriés — même en tant que solution de repli de priorité inférieure qui n’est finalement pas sélectionnée — car la décision est prise avant que l’algorithme ne soit choisi. Il existe deux effets de ce type :

• L’inférence de type des clés de jointure devient plus stricte (une jointure par fusion ne peut pas joindre des clés de types différents, par exemple String et Nullable(String)). Cela peut modifier les types de résultat des colonnes USING et entraîner l’échec d’une jointure avec une table du moteur Join avec TYPE_MISMATCH. Déclenché par full_sorting_merge et parallel_full_sorting_merge.
• ORDER BY ... LIMIT du côté préservé d’une jointure reçoit un tri explicite au lieu d’une lecture dans l’ordre de la clé primaire, car la jointure est supposée interrompre la lecture ordonnée (une jointure par fusion insère son propre tri avant la jointure ; une jointure par fusion partielle retrie les blocs de gauche ; une jointure pouvant produire des blocs retardés ne propage pas non plus la lecture ordonnée). Le résultat est le même, mais le plan est moins efficace. Déclenché par full_sorting_merge, parallel_full_sorting_merge, partial_merge, prefer_partial_merge, grace_hash et auto, ainsi que par une valeur non nulle de max_bytes_before_external_join / max_bytes_ratio_before_external_join.

Les deux s’appliquent même lorsque la requête s’exécute finalement avec hash ou un autre algorithme. Si cela n’est pas souhaitable, ne répertoriez pas les algorithmes ci-dessus dans join_algorithm pour les requêtes concernées. Valeurs possibles :

• grace_hash

Le grace hash join est utilisé. Grace hash fournit une option d’algorithme permettant d’exécuter des jointures complexes de manière performante tout en limitant l’utilisation de la mémoire. La première phase d’une grace join lit la table de droite et la divise en N buckets selon la valeur de hachage des colonnes clés (initialement, N vaut grace_hash_join_initial_buckets). Cela est fait de façon à garantir que chaque bucket puisse être traité indépendamment. Les lignes du premier bucket sont ajoutées à une table de hachage en mémoire, tandis que les autres sont enregistrées sur disque. Si la table de hachage dépasse la limite de mémoire (par exemple, telle que définie par max_bytes_in_join, le nombre de buckets augmente, ainsi que le bucket attribué à chaque ligne. Toutes les lignes qui n’appartiennent pas au bucket courant sont vidées et réattribuées. Prend en charge INNER/LEFT/RIGHT/FULL ALL/ANY JOIN.

• hash

L’algorithme de hash join est utilisé. Il s’agit de l’implémentation la plus générique, qui prend en charge toutes les combinaisons de type et de strictness, ainsi que plusieurs clés de jointure combinées avec OR dans la section JOIN ON. Lors de l’utilisation de l’algorithme hash, la partie droite de JOIN est chargée en RAM.

• parallel_hash

Une variante de la jointure hash qui divise les données en buckets et construit plusieurs tables de hachage en parallèle au lieu d’une seule afin d’accélérer ce processus. Lors de l’utilisation de l’algorithme parallel_hash, la partie droite de JOIN est chargée en RAM.

• partial_merge

Une variante de l’algorithme sort-merge, dans laquelle seule la table de droite est entièrement triée. RIGHT JOIN et FULL JOIN ne sont pris en charge qu’avec la strictness ALL (SEMI, ANTI, ANY et ASOF ne sont pas pris en charge). Lors de l’utilisation de l’algorithme partial_merge, ClickHouse trie les données et les écrit sur disque. L’algorithme partial_merge de ClickHouse diffère légèrement de l’implémentation classique. D’abord, ClickHouse trie la table de droite par clés de jointure, par blocs, et crée un index min-max pour les blocs triés. Ensuite, il trie des parties de la table de gauche par join key et les joint à la table de droite. L’index min-max est également utilisé pour ignorer les blocs inutiles de la table de droite.

• direct

L’algorithme direct (également appelé boucle imbriquée) effectue une recherche dans la table de droite en utilisant les lignes de la table de gauche comme clés. Il est pris en charge par des stockages spéciaux tels que Dictionary, EmbeddedRocksDB et les tables MergeTree. Pour les tables MergeTree, l’algorithme pousse directement les filtres de clé de jointure vers la couche de stockage. Cela peut être plus efficace lorsque la clé peut utiliser l’index de clé primaire de la table pour les recherches ; sinon, il effectue un parcours complet de la table de droite pour chaque bloc de la table de gauche. Prend en charge les jointures INNER et LEFT, et uniquement des clés de jointure d’égalité sur une seule colonne, sans autre condition.

• auto

Lorsqu’il est défini sur auto, la jointure hash est essayée en premier, et l’algorithme bascule à la volée vers un autre algorithme si la limite de mémoire est dépassée.

• full_sorting_merge

Algorithme sort-merge avec tri complet des tables jointes avant la jointure.

• ie_join

L’algorithme IEJoin basé sur le tri est destiné aux JOIN dont la section ON comporte deux comparaisons d’inégalité (<, <=, >, >=) entre des expressions des tables jointes. Prend en charge ALL INNER/LEFT/RIGHT/FULL JOIN et les SEMI/ANTI LEFT/RIGHT JOIN. La position dans la liste définit la priorité : répertorié après les autres algorithmes, IEJoin est utilisé uniquement lorsqu’ils ne s’appliquent pas (la section ON ne comporte aucune condition d’égalité) ; répertorié en premier, il est utilisé chaque fois que la section ON comporte deux conditions d’inégalité. Les conditions restantes (y compris les égalités) sont appliquées comme filtre sur le résultat de la jointure pour ALL INNER JOIN, et évaluées au sein de l’opérateur comme condition résiduelle affectant la correspondance pour les autres types. Sans ie_join dans la liste, une INNER JOIN ne comportant que des conditions d’inégalité est exécutée comme une CROSS JOIN avec un filtre, et les autres types ne sont pas pris en charge. Les deux entrées sont accumulées en mémoire avant la jointure : max_rows_in_join et max_bytes_in_join limitent les entrées accumulées des deux côtés confondus (et pas seulement du côté droit), avec l’action en cas de dépassement définie par join_overflow_mode ; les index de tri que l’opérateur construit à partir des entrées accumulées ne sont pas comptabilisés dans la limite. L’opérateur de jointure lui-même s’exécute dans un seul thread ; seuls les tris des entrées avant la jointure sont parallélisés.

• parallel_full_sorting_merge

Identique à full_sorting_merge, mais les jointures d’égalité compatibles avec le hachage sont partitionnées par le hachage des clés de jointure en jointures par fusion indépendantes par segment qui s’exécutent en parallèle (jusqu’à max_threads), au lieu d’une seule jointure par fusion. Cela conserve la faible utilisation de mémoire en flux d’une jointure par fusion tout en utilisant tous les threads, et le résultat n’est pas ordonné. Le partitionnement par hachage des clés de jointure s’applique uniquement aux jointures d’égalité simples sur des types de clés dont le hachage concorde avec la comparaison de jointure par fusion, et uniquement lorsqu’aucun côté n’est déjà trié. Il est ignoré dans les cas suivants :

• Les jointures ASOF, et les types de clés à virgule flottante / JSON / Object / Dynamic : leurs hachages ne sont pas cohérents avec la comparaison de jointure par fusion, de sorte que des clés égales pourraient se retrouver dans des segments différents.
• Les côtés déjà triés (une lecture MergeTree dans l’ordre, ou toute entrée prétriée) : une dispersion préservant l’ordre dans les fusions par segment peut provoquer un interblocage du pipeline. La lecture dans l’ordre et son optimisation read_in_order_use_virtual_row sont conservées à la place.
• Pendant que l’initiateur construit un plan distribué (make_distributed_plan), car le tri dispersé n’est pas sérialisable pour une exécution distante. Le plan local à fragment unique et les fragments par worker se réoptimisent avec ce paramètre désactivé, afin qu’ils puissent tout de même être partitionnés.

L’ignorer désactive uniquement cette réécriture, et non le parallélisme en général : la jointure s’exécute comme une unique full_sorting_merge, et les côtés MergeTree lus dans l’ordre peuvent toujours être partitionnés à la source par plages de clés primaires (qui s’ordonnent selon la même comparaison que celle utilisée par la jointure, de sorte que les clés égales restent ensemble) lorsque query_plan_join_shard_by_pk_ranges est activé.

• prefer_partial_merge

ClickHouse essaie toujours d’utiliser la jointure partial_merge si possible, sinon il utilise hash. Déprécié, identique à partial_merge,hash.

• default (déprécié)

Valeur héritée, veuillez ne plus l’utiliser. Identique à direct,hash, c’est-à-dire qu’il essaie d’utiliser une jointure directe puis une jointure par hachage (dans cet ordre). Modifie le comportement des opérations de jointure de type ANY lorsque la table de droite contient plus d’une ligne correspondante pour une clé. Valeurs possibles :

• 0 — Si la table de droite contient plus d’une ligne correspondante, seule la première trouvée est utilisée pour la jointure.
• 1 — Si la table de droite contient plus d’une ligne correspondante, seule la dernière trouvée est utilisée pour la jointure.

Voir aussi :

• clause JOIN
• moteur de table Join
• join_default_strictness

Définit la strictness par défaut des clauses JOIN. Valeurs possibles :

• ALL — Si la table de droite comporte plusieurs lignes correspondantes, ClickHouse crée un produit cartésien à partir de ces lignes. Il s’agit du comportement JOIN ordinaire du SQL standard.
• ANY — Si la table de droite comporte plusieurs lignes correspondantes, seule la première trouvée est utilisée pour la jointure. Si la table de droite ne comporte qu’une seule ligne correspondante, les résultats de ANY et ALL sont identiques.
• ASOF — Pour joindre des séquences avec une correspondance incertaine.
• Chaîne vide — Si ALL ou ANY n’est pas spécifié dans la requête, ClickHouse lève une exception.

Limite le nombre de fichiers autorisés pour le tri parallèle lors des opérations MergeJoin exécutées sur disque. Plus la valeur du paramètre est élevée, plus la quantité de RAM utilisée augmente et moins les E/S disque sont nécessaires. Valeurs possibles :

• Tout entier positif à partir de 2.

La limite inférieure de la moyenne de lignes par clé dans la table de droite, utilisée pour déterminer s’il faut produire la sortie sous forme de liste de lignes dans un hash join. Définit l’action effectuée par ClickHouse lorsqu’une jointure atteint l’une des limites suivantes :

• max_bytes_in_join
• max_rows_in_join

Ce paramètre n’est respecté que pour les valeurs hash, parallel_hash et ie_join de join_algorithm. Les autres algorithmes (par exemple, partial_merge, grace_hash, auto) gèrent ces limites différemment — en écrivant sur disque, en repartitionnant ou en changeant de stratégie — voir join_algorithm. Valeurs possibles :

• THROW — ClickHouse lève une exception et arrête la requête.
• BREAK — ClickHouse arrête la requête sans lever d’exception.

Valeur par défaut : THROW. Voir aussi

• clause JOIN
• moteur de table Join

Définit le comportement de JOIN. Lors de la jointure de tables, des cellules vides peuvent apparaître. ClickHouse les remplit différemment selon ce paramètre. Valeurs possibles :

• 0 — Les cellules vides sont remplies avec la valeur par défaut du type du champ correspondant.
• 1 — JOIN se comporte comme en standard SQL. Le type du champ correspondant est converti en Nullable, et les cellules vides sont remplies avec NULL.