paramètres de session max_bytes_*

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

​

max_bytes_before_external_distinct

Seuil de mémoire de la requête, en octets, à partir duquel les données DISTINCT sont déversées sur disque. L’utilisation réelle de la mémoire peut dépasser ce seuil. 0 désactive ce seuil. Si max_bytes_ratio_before_external_distinct définit lui aussi un seuil, c’est le plus petit des deux qui est retenu. Définissez les deux paramètres à 0 pour désactiver le déversement. Voir DISTINCT en mémoire externe.

​

max_bytes_before_external_group_by

Valeur par défaut dans Cloud : la moitié de la quantité de mémoire de chaque réplique. Active ou désactive l’exécution des clauses GROUP BY en mémoire externe. (Voir GROUP BY en mémoire externe) Valeurs possibles :

• Volume maximal de RAM (en octets) pouvant être utilisé par une seule opération GROUP BY.
• 0 — GROUP BY en mémoire externe désactivé.

​

max_bytes_before_external_join

S’il est défini sur une valeur non nulle, le hash join sera automatiquement converti en grace hash join pour permettre le déversement sur disque lorsque les données du côté droit dépassent ce nombre d’octets. Conjointement avec max_bytes_ratio_before_external_join, il constitue le déclencheur de déversement basé sur un seuil pour tout join_algorithm reposant sur le hachage, y compris grace_hash, qui exige que l’un des deux soit non nul. Dès qu’un seuil non nul rend une join capable de déverser sur disque, enable_adaptive_memory_spill_scheduler peut la forcer à déverser sous pression mémoire avant que le seuil ne soit atteint ; si les deux paramètres valent 0, la join ne déverse jamais et le scheduler n’a donc rien à déclencher. L’exception est legacy_join_size_limits_trigger_spilling : lorsqu’il est activé, un grace_hash standalone ignore les deux et déverse en fonction de max_rows_in_join / max_bytes_in_join à la place. Lorsqu’il est défini sur 0 (valeur par défaut), ce seuil absolu en octets est désactivé, mais un déversement sur disque automatique peut toujours se produire via max_bytes_ratio_before_external_join (qui vaut par défaut 0.5) ; définissez les deux sur 0 pour désactiver complètement le déversement sur disque automatique. Cela empêche l’optimisation de lecture read in order via join.

​

max_bytes_before_external_sort

Valeur par défaut dans Cloud : la moitié de la mémoire par réplique. Active ou désactive l’exécution des clauses ORDER BY en mémoire externe. Voir Détails d’implémentation de ORDER BY Si l’utilisation de la mémoire pendant l’opération ORDER BY dépasse ce seuil en octets, le mode de « tri externe » (écriture des données sur disque) est activé. Valeurs possibles :

• Volume maximal de RAM (en octets) pouvant être utilisé par une seule opération ORDER BY. La valeur recommandée est la moitié de la mémoire système disponible
• 0 — ORDER BY en mémoire externe désactivé.

​

max_bytes_before_remerge_sort

Dans le cas d’un ORDER BY avec LIMIT, lorsque l’utilisation de la mémoire dépasse le seuil spécifié, effectuez des étapes supplémentaires de fusion de blocs avant la fusion finale afin de ne conserver que les LIMIT premières lignes.

​

max_bytes_for_lazy_final

Nombre maximal d’octets dans l’ensemble utilisé pour l’optimisation lazy FINAL. Au-delà de cette limite, le système revient à FINAL standard.

​

max_bytes_in_distinct

Nombre maximal d’octets de l’état (en octets non compressés) en mémoire, utilisé par une table de hachage avec DISTINCT.

​

max_bytes_in_join

La taille maximale, en octets, de la structure de données située du côté droit (généralement une table de hachage) utilisée lors de la jointure de tables. Ce paramètre s’applique aux opérations SELECT … JOIN et au moteur de table Join. Si une requête contient plusieurs jointures, ClickHouse vérifie ce paramètre pour chaque résultat intermédiaire. Il s’agit d’un plafond strict pour tout join_algorithm fondé sur le hachage : lorsque la limite est atteinte, la requête lève une exception ou s’interrompt selon join_overflow_mode. Il ne provoque jamais le spill d’une jointure sur disque — cette décision relève de max_bytes_before_external_join et de max_bytes_ratio_before_external_join. Comme il s’agit d’un plafond et non d’un déclencheur, le définir au niveau du seuil de spill ou en dessous fait normalement échouer la requête avant même que la jointure puisse faire du spill — sauf si la jointure est capable de spill et que enable_adaptive_memory_spill_scheduler force d’abord un spill, ou si legacy_join_size_limits_trigger_spilling reconvertit cette limite en déclencheur de spill pour la partie d’une jointure qui s’exécute déjà sur disque. La limite comptabilise le contenu des tables de hachage : ainsi, une jointure ayant fait du spill l’atteint au fur et à mesure du chargement de chaque bucket plutôt que pendant la lecture du côté droit ; elle peut donc lire une plus grande part du côté droit avant de s’arrêter qu’une hash join en mémoire. Valeurs possibles :

• Entier positif.
• 0 — Le contrôle de la mémoire est désactivé.

​

max_bytes_in_set

Le nombre maximal d’octets (de données non compressées) qu’un ensemble dans la clause IN créé à partir d’une sous-requête peut utiliser.

​

max_bytes_ratio_before_external_distinct

Fraction de la mémoire disponible du serveur ou de l’utilisateur servant à calculer le seuil de DISTINCT externe au début de l’exécution. Par exemple, 0.5 utilise la moitié de la mémoire disponible. Les valeurs doivent être supérieures ou égales à 0 et inférieures à 1. La valeur 0 désactive ce seuil. En l’absence de limite de mémoire applicable au serveur ou à l’utilisateur, le ratio n’a aucun effet. max_memory_usage n’intervient pas dans ce calcul. Pour configurer le déversement par rapport à cette limite, utilisez max_bytes_before_external_distinct, en laissant de la marge pour une utilisation supplémentaire de la mémoire.

​

max_bytes_ratio_before_external_group_by

La proportion de mémoire disponible pouvant être utilisée par GROUP BY. Une fois ce seuil atteint, la mémoire externe est utilisée pour l’agrégation. Par exemple, si cette valeur est définie sur 0.6, GROUP BY pourra utiliser 60 % de la mémoire disponible (pour server/user/merges) au début de l’exécution ; ensuite, il commencera à utiliser l’agrégation externe.

​

max_bytes_ratio_before_external_join

Ratio de mémoire disponible autorisé pour JOIN. Une fois ce seuil atteint, le hash join est converti en grace hash join afin de déverser les données du côté droit sur disque. Par exemple, si cette valeur est définie sur 0.6, JOIN autorise l’utilisation de 60% de la mémoire disponible (pour le serveur/l’utilisateur/les fusions) pour la table de hachage du côté droit au début de l’exécution ; au-delà, le déversement sur disque commence. Si max_bytes_before_external_join et max_bytes_ratio_before_external_join sont tous deux définis, c’est le plus petit seuil obtenu qui est utilisé. Si le ratio vaut 0, seule la valeur absolue s’applique. A un effet pour tous les join_algorithm basés sur le hachage, y compris grace_hash, à condition qu’un chemin de données temporaire soit configuré.

​

max_bytes_ratio_before_external_sort

Rapport de la mémoire disponible pouvant être utilisé pour ORDER BY. Une fois cette limite atteinte, le tri externe est utilisé. Par exemple, s’il est défini sur 0.6, ORDER BY pourra utiliser 60% de la mémoire disponible (pour server/user/merges) au début de l’exécution, puis il commencera à utiliser le tri externe. Notez que max_bytes_before_external_sort reste pris en compte : le déversement sur disque n’a lieu que si le bloc de tri est plus grand que max_bytes_before_external_sort.

​

max_bytes_to_read

Le nombre maximal d’octets (de données non compressées) pouvant être lus à partir d’une table lors de l’exécution d’une requête. La restriction est vérifiée pour chaque fragment de données traité, s’applique uniquement à l’expression de table la plus imbriquée et, lors d’une lecture depuis un serveur distant, elle est vérifiée uniquement sur le serveur distant.

​

max_bytes_to_read_leaf

Le nombre maximal d’octets (de données non compressées) pouvant être lus à partir d’une table locale sur un nœud feuille lors de l’exécution d’une requête distribuée. Bien que les requêtes distribuées puissent envoyer plusieurs sous-requêtes à chaque shard (feuille), cette limite n’est vérifiée qu’à l’étape de lecture sur les nœuds feuille et est ignorée lors de l’étape de fusion des résultats sur le nœud racine. Par exemple, un cluster se compose de 2 shards et chaque shard contient une table avec 100 octets de données. Une requête distribuée censée lire toutes les données des deux tables avec le paramètre max_bytes_to_read=150 échouera, car le total sera de 200 octets. Une requête avec max_bytes_to_read_leaf=150 réussira puisque les nœuds feuille liront au maximum 100 octets. La restriction est vérifiée pour chaque fragment de données traité.

​

max_bytes_to_sort

Le nombre maximal d’octets avant le tri. Si l’opération ORDER BY doit traiter plus d’octets non compressés que la quantité spécifiée, le comportement sera déterminé par sort_overflow_mode, qui est défini par défaut sur throw.

​

max_bytes_to_transfer

Le nombre maximal d’octets (données non compressées) pouvant être transmis à un serveur distant ou enregistrés dans une table temporaire lors de l’exécution de la section GLOBAL IN/JOIN.