Paramètres de session

Paramètres présents dans la table system.settings.

Tous les paramètres ci-dessous sont également disponibles dans la table system.settings. Ces paramètres sont générés automatiquement à partir du code source.

​

add_http_cors_header

Ajouter l’en-tête HTTP CORS.

​

additional_result_filter

Expression de filtre supplémentaire à appliquer au résultat de la requête SELECT. Ce paramètre ne s’applique à aucune sous-requête.

Exemple

INSERT INTO table_1 VALUES (1, 'a'), (2, 'bb'), (3, 'ccc'), (4, 'dddd');
SElECT * FROM table_1;

┌─x─┬─y────┐
│ 1 │ a    │
│ 2 │ bb   │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

SELECT *
FROM table_1
SETTINGS additional_result_filter = 'x != 2'

┌─x─┬─y────┐
│ 1 │ a    │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

​

additional_table_filters

Une expression de filtre supplémentaire appliquée après la lecture de la table indiquée.

Exemple

INSERT INTO table_1 VALUES (1, 'a'), (2, 'bb'), (3, 'ccc'), (4, 'dddd');
SELECT * FROM table_1;

┌─x─┬─y────┐
│ 1 │ a    │
│ 2 │ bb   │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

SELECT *
FROM table_1
SETTINGS additional_table_filters = {'table_1': 'x != 2'}

┌─x─┬─y────┐
│ 1 │ a    │
│ 3 │ ccc  │
│ 4 │ dddd │
└───┴──────┘

​

aggregate_function_input_format

Format d’entrée d’AggregateFunction lors des opérations INSERT.

Valeurs possibles :

• state — Chaîne binaire contenant l’état sérialisé (par défaut). Il s’agit du comportement par défaut, dans lequel les valeurs AggregateFunction sont attendues sous forme de données binaires.
• value — Le format attend une seule valeur de l’argument de la fonction d’agrégation ou, dans le cas de plusieurs arguments, un tuple de ces valeurs. Elles seront désérialisées à l’aide du IDataType ou du DataTypeTuple correspondant, puis agrégées pour former l’état.
• array — Le format attend un Array de valeurs, comme décrit dans l’option value ci-dessus. Tous les éléments du tableau seront agrégés pour former l’état.

Exemples

Pour une table ayant la structure suivante :

CREATE TABLE example (
    user_id UInt64,
    avg_session_length AggregateFunction(avg, UInt32)
);

Avec aggregate_function_input_format = 'value' :

INSERT INTO example FORMAT CSV
123,456

Avec aggregate_function_input_format = 'array' :

INSERT INTO example FORMAT CSV
123,"[456,789,101]"

Remarque : les formats value et array sont plus lents que le format state par défaut, car ils nécessitent la création et l’agrégation de valeurs lors de l’insertion.

​

aggregate_functions_null_for_empty

Active ou désactive la réécriture de toutes les fonctions d’agrégation d’une requête en leur ajoutant le suffixe -OrNull. Activez ce paramètre pour assurer la compatibilité avec la norme SQL. Cette fonctionnalité est implémentée via une réécriture de requête (similaire au paramètre count_distinct_implementation) afin d’obtenir des résultats cohérents pour les requêtes distribuées.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Exemple

Prenons la requête suivante avec des fonctions d’agrégation :

SELECT SUM(-1), MAX(0) FROM system.one WHERE 0;

Avec aggregate_functions_null_for_empty = 0, on obtiendrait :

┌─SUM(-1)─┬─MAX(0)─┐
│       0 │      0 │
└─────────┴────────┘

Avec aggregate_functions_null_for_empty = 1, le résultat serait :

┌─SUMOrNull(-1)─┬─MAXOrNull(0)─┐
│          NULL │         NULL │
└───────────────┴──────────────┘

​

aggregation_in_order_max_block_bytes

Taille maximale du bloc, en octets, accumulé lors de l’agrégation selon l’ordre de la clé primaire. Une taille de bloc plus faible permet de paralléliser davantage l’étape finale de fusion de l’agrégation.

​

aggregation_memory_efficient_merge_threads

Nombre de threads à utiliser pour fusionner les résultats intermédiaires d’agrégation en mode économe en mémoire. Plus cette valeur est élevée, plus la mémoire consommée est importante. 0 signifie : identique à ‘max_threads’.

​

ai_function_credentials

Nom de la collection nommée utilisée par les fonctions d’IA pour les identifiants du fournisseur et la configuration (provider, endpoint, model, api_key facultative, etc.). Lorsqu’elle est vide, une exception est levée.

​

ai_function_embedding_max_batch_size

Nombre maximal de textes à inclure dans une seule requête HTTP effectuée par aiEmbed. Les textes sont regroupés en lots de cette taille afin de réduire la surcharge liée aux appels à l’API. Par exemple, 500 textes uniques avec une taille de lot de 100 donnent lieu à 5 requêtes HTTP.

​

ai_function_max_api_calls_per_query

Nombre maximal de requêtes HTTP que les fonctions d’IA peuvent envoyer par requête. Définissez cette valeur sur 0 pour désactiver ce paramètre.

​

ai_function_max_input_tokens_per_query

Nombre maximal total de tokens d’entrée (prompt) pour l’ensemble des appels d’API à la fonction d’IA au sein d’une même requête. Ce total est comptabilisé de manière cumulative à partir des réponses du fournisseur. Notez que cette limite peut être dépassée à hauteur des tokens d’entrée d’un appel, car le nombre de tokens d’entrée d’un appel n’est pas connu à l’avance. Définissez-la sur 0 pour la désactiver.

Cette limite n’est appliquée qu’aux fournisseurs qui renvoient un objet usage dans leur réponse (OpenAI, Anthropic, vLLM). Les fournisseurs qui n’indiquent pas l’usage des tokens (notamment HuggingFace TEI) font que le compteur reste à 0 — utilisez plutôt ai_function_max_api_calls_per_query pour plafonner ce type d’appels.

​

ai_function_max_output_tokens_per_query

Nombre total maximal de tokens de sortie (complétion) sur l’ensemble des appels à l’API de fonction d’IA au sein d’une même requête. Le suivi est cumulatif à partir des réponses du fournisseur. Notez que cette limite peut être dépassée à hauteur des tokens de sortie d’un appel, car leur nombre n’est pas connu à l’avance. Définissez cette valeur sur 0 pour la désactiver.

Cette limite n’est appliquée qu’aux fournisseurs qui renvoient un objet usage dans leur réponse (OpenAI, Anthropic, vLLM). Elle ne s’applique pas aux fonctions d’embedding (notamment aiEmbed), qui ne produisent jamais de tokens de sortie.

​

ai_function_max_retries

Nombre maximal de tentatives de réessai en cas d’erreur transitoire pour chaque requête API. Chaque réessai utilise un backoff exponentiel à partir de ai_function_retry_initial_delay_ms.

​

ai_function_request_timeout_sec

Délai d’expiration, en secondes, des requêtes HTTP individuelles effectuées par les fonctions d’IA (complétions de chat IA et appels à l’API d’embedding). Si une requête ne s’achève pas dans ce délai, elle est considérée comme échouée et peut être retentée conformément à ai_function_max_retries.

​

ai_function_retry_initial_delay_ms

Délai initial, en millisecondes, avant la première nouvelle tentative d’une requête d’API vers une fonction d’IA ayant échoué. Le délai double à chaque tentative suivante (backoff exponentiel). Par exemple, avec les paramètres par défaut : 1000ms, 2000ms, 4000ms.

​

ai_function_throw_on_error

Si true (par défaut), un appel à une fonction d’IA qui échoue définitivement après avoir épuisé toutes les nouvelles tentatives interrompt la requête en levant une exception. Si false, la ligne ayant échoué reçoit la valeur par défaut du type de colonne (chaîne vide pour String) et le traitement se poursuit.

​

ai_function_throw_on_quota_exceeded

Si true (par défaut), le dépassement d’une limite de quota d’une fonction d’IA (ai_function_max_input_tokens_per_query, ai_function_max_output_tokens_per_query ou ai_function_max_api_calls_per_query) interrompt la requête en renvoyant une exception. Si false, les lignes restantes reçoivent la valeur par défaut du type de colonne (chaîne vide pour String).

​

allow_aggregate_partitions_independently

Active l’agrégation indépendante des partitions sur des threads distincts lorsque la clé de partition est adaptée à la clé de regroupement. Utile lorsque le nombre de partitions est proche du nombre de cœurs et que les partitions ont à peu près la même taille

​

allow_archive_path_syntax

Les moteurs File/S3 et la fonction de table interprètent les chemins contenant ’::’ comme <archive> :: <file> si l’archive a l’extension appropriée.

​

allow_asynchronous_read_from_io_pool_for_merge_tree

Utilise le pool d’E/S d’arrière-plan pour lire les tables MergeTree. Ce paramètre peut améliorer les performances des requêtes limitées par les E/S

​

allow_calculating_subcolumns_sizes_for_merge_tree_reading

Lorsqu’il est activé, ClickHouse calcule la taille des fichiers nécessaires à la lecture de chaque sous-colonne afin d’améliorer le calcul de la taille des tâches et des blocs.

​

allow_changing_replica_until_first_data_packet

S’il est activé, dans les requêtes hedged, nous pouvons démarrer une nouvelle connexion jusqu’à la réception du premier paquet de données, même si nous avons déjà enregistré un certain Progress (mais que le Progress n’a pas été mis à jour pendant le délai d’attente receive_data_timeout) ; sinon, nous désactivons le changement de réplique après la première fois où nous avons enregistré un Progress.

​

allow_create_index_without_type

Autorise la requête CREATE INDEX sans TYPE. La requête est alors ignorée. Prévu pour les tests de compatibilité SQL.

​

allow_custom_error_code_in_throwif

Active l’utilisation d’un code d’erreur personnalisé dans la fonction throwIf(). Si true, les exceptions levées peuvent avoir des codes d’erreur inattendus.

​

allow_ddl

S’il est défini sur true, l’utilisateur est autorisé à exécuter des requêtes DDL.

​

allow_deprecated_database_ordinary

Autorise la création de bases de données avec le moteur Ordinary déprécié

​

allow_deprecated_error_prone_window_functions

Autoriser l’utilisation de fonctions de fenêtre obsolètes propices aux erreurs (neighbor, runningAccumulate, runningDifferenceStartingWithFirstValue, runningDifference)

​

allow_deprecated_snowflake_conversion_functions

Les fonctions snowflakeToDateTime, snowflakeToDateTime64, dateTimeToSnowflake et dateTime64ToSnowflake sont obsolètes et désactivées par défaut. Veuillez utiliser les fonctions snowflakeIDToDateTime, snowflakeIDToDateTime64, dateTimeToSnowflakeID et dateTime64ToSnowflakeID à la place.

Pour réactiver les fonctions obsolètes (par exemple pendant une période de transition), définissez ce paramètre sur true.

​

allow_deprecated_syntax_for_merge_tree

Autorise la création de tables *MergeTree avec une syntaxe obsolète de définition du moteur

​

allow_distributed_ddl

S’il est défini sur true, un utilisateur est autorisé à exécuter des requêtes DDL distribuées.

​

allow_drop_detached

Autorise les requêtes ALTER TABLE … DROP DETACHED PART[ITION] …

​

allow_dynamic_type_in_join_keys

Autorise l’utilisation du type Dynamic dans les clés de JOIN. Ajouté pour des raisons de compatibilité. Il n’est pas recommandé d’utiliser le type Dynamic dans les clés de JOIN, car la comparaison avec d’autres types peut produire des résultats inattendus.

​

allow_execute_multiif_columnar

Autoriser l’exécution de la fonction multiIf en mode colonnaire

​

allow_experimental_ai_functions

Active les fonctions d’IA expérimentales (par ex. aiGenerateContent). Ces fonctions effectuent des appels HTTP externes vers des fournisseurs d’IA.

​

allow_experimental_analyzer

Aliases: enable_analyzer

Autorise le nouvel analyseur de requêtes.

​

allow_experimental_cleanup_old_data_files_compaction

Autorise le nettoyage des anciens fichiers de données lors de la compaction d’Iceberg.

​

allow_experimental_codecs

Si cette option est définie sur true, elle permet de spécifier des codecs de compression expérimentaux (mais il n’en existe pas encore, donc cette option n’a aucun effet).

​

allow_experimental_correlated_subqueries

Permet d’exécuter des sous-requêtes corrélées.

​

allow_experimental_database_glue_catalog

Alias : allow_database_glue_catalog

Autoriser le moteur de base de données expérimental DataLakeCatalog avec catalog_type = ‘glue’

Valeur par défaut dans Cloud : 1.

​

allow_experimental_database_hms_catalog

Autoriser le moteur de base de données expérimental DataLakeCatalog avec catalog_type = ‘hms’

​

allow_experimental_database_iceberg

Alias : allow_database_iceberg

Autorise l’utilisation du moteur de base de données expérimental DataLakeCatalog avec catalog_type = ‘iceberg’

Valeur par défaut dans Cloud : 1.

​

allow_experimental_database_materialized_postgresql

Autorise la création d’une base de données avec Engine=MaterializedPostgreSQL(…).

​

allow_experimental_database_paimon_rest_catalog

Autorise le moteur de base de données expérimental DataLakeCatalog avec catalog_type = ‘paimon_rest’

​

allow_experimental_database_unity_catalog

Alias : allow_database_unity_catalog

Autoriser le moteur de base de données expérimental DataLakeCatalog avec catalog_type = ‘unity’

Valeur par défaut dans Cloud : 1.

​

allow_experimental_delta_kernel_rs

Autorise l’implémentation expérimentale de delta-kernel-rs.

​

allow_experimental_delta_lake_writes

Active la fonctionnalité d’écriture de delta-kernel.

​

allow_experimental_expire_snapshots

Autorise l’exécution de la commande expérimentale Iceberg ALTER TABLE ... EXECUTE expire_snapshots.

​

allow_experimental_funnel_functions

Active les fonctions expérimentales d’analyse de funnel.

​

allow_experimental_geo_types_in_iceberg

Autorise l’analyse des types de champ geometry et geography d’Iceberg en tant que type Geometry (Variant) de ClickHouse.

​

allow_experimental_hash_functions

Active les fonctions de hachage expérimentales

​

allow_experimental_iceberg_compaction

Permet d’utiliser explicitement ‘OPTIMIZE’ sur les tables Iceberg.

​

allow_experimental_join_right_table_sorting

Si cette option est définie sur true et que les conditions de join_to_sort_minimum_perkey_rows et join_to_sort_maximum_table_rows sont remplies, la table de droite est réorganisée par clé afin d’améliorer les performances d’une jointure par hachage left ou inner.

​

allow_experimental_json_lazy_type_hints

Active les indications de type différées expérimentales pour le type JSON. Cette fonctionnalité permet d’optimiser les conversions de type JSON en reportant l’évaluation des indications de type.

​

allow_experimental_kafka_offsets_storage_in_keeper

Autorise la fonctionnalité expérimentale de stockage des offsets liés à Kafka dans ClickHouse Keeper. Lorsqu’elle est activée, un chemin ClickHouse Keeper et un nom de réplique peuvent être spécifiés pour le moteur de table Kafka. Par conséquent, au lieu du moteur Kafka habituel, un nouveau type de moteur de stockage sera utilisé, stockant principalement les offsets validés dans ClickHouse Keeper

​

allow_experimental_kusto_dialect

Activez Kusto Query Language (KQL), une alternative à SQL.

​

allow_experimental_materialized_postgresql_table

Permet d’utiliser le moteur de table MaterializedPostgreSQL. Désactivée par défaut, car cette fonctionnalité est expérimentale

​

allow_experimental_nlp_functions

Active les fonctions expérimentales de traitement du langage naturel.

​

allow_experimental_nullable_tuple_type

Alias : enable_nullable_tuple_type

Autorise la création de colonnes Nullable Tuple dans les tables.

Ce paramètre ne détermine pas si les sous-colonnes de tuple extraites peuvent être Nullable (par exemple à partir de colonnes Dynamic, Variant, JSON ou Tuple). Utilisez allow_nullable_tuple_in_extracted_subcolumns pour définir si les sous-colonnes de tuple extraites peuvent être Nullable.

​

allow_experimental_object_storage_queue_hive_partitioning

Permet d’utiliser le partitionnement Hive avec les moteurs S3Queue/AzureQueue

​

allow_experimental_paimon_storage_engine

Autorise la création de tables avec les moteurs de table Paimon*.

​

allow_experimental_parallel_reading_from_replicas

Alias : enable_parallel_replicas

Utilise jusqu’à max_parallel_replicas répliques de chaque shard pour exécuter les requêtes SELECT. La lecture est parallélisée et coordonnée dynamiquement. 0 - désactivé, 1 - activé, avec désactivation silencieuse en cas d’échec, 2 - activé, avec levée d’une exception en cas d’échec

​

allow_experimental_polyglot_dialect

Active le transpileur SQL polyglotte ; il convertit le SQL de plus de 30 dialectes (MySQL, PostgreSQL, SQLite, Snowflake, DuckDB, etc.) en ClickHouse SQL.

​

allow_experimental_prql_dialect

Active PRQL, une alternative à SQL.

​

allow_experimental_text_index_lazy_apply

Si cette option est définie sur true, elle permet d’utiliser le mode d’application différée de la posting list pour les requêtes d’index de texte.

​

allow_experimental_time_series_aggregate_functions

Alias : allow_experimental_ts_to_grid_aggregate_function

Fonctions d’agrégation expérimentales timeSeries* pour le rééchantillonnage de séries temporelles de type Prometheus, ainsi que pour le calcul du taux et du delta.

​

allow_experimental_time_series_table

Permet de créer des tables avec le moteur de table TimeSeries. Valeurs possibles :

• 0 — le moteur de table TimeSeries est désactivé.
• 1 — le moteur de table TimeSeries est activé.

​

allow_experimental_unique_key

Permet de créer des tables avec la clause UNIQUE KEY sur les moteurs de la famille MergeTree.

​

allow_experimental_window_view

Active WINDOW VIEW. Fonctionnalité pas encore suffisamment mature.

​

allow_experimental_ytsaurus_dictionary_source

Source de dictionnaire expérimentale pour l’intégration avec YTsaurus.

​

allow_experimental_ytsaurus_table_engine

Moteur de table expérimental pour l’intégration avec YTsaurus.

​

allow_experimental_ytsaurus_table_function

Moteur de table expérimental pour l’intégration à YTsaurus.

​

allow_fuzz_query_functions

Active la fonction fuzzQuery, qui applique des mutations aléatoires de l’AST à une chaîne de requête.

​

allow_general_join_planning

Autorise un algorithme de planification des jointures plus générique, capable de gérer des conditions plus complexes, mais qui fonctionne uniquement avec la jointure de hachage. Si la jointure de hachage n’est pas activée, l’algorithme habituel de planification des jointures est utilisé, quelle que soit la valeur de ce paramètre.

​

allow_get_client_http_header

Autorise l’utilisation de la fonction getClientHTTPHeader, qui permet d’obtenir la valeur d’un en-tête de la requête HTTP en cours. Elle n’est pas activée par défaut pour des raisons de sécurité, car certains en-têtes, comme Cookie, peuvent contenir des informations sensibles. Notez que les en-têtes X-ClickHouse-* et Authentication sont toujours restreints et ne peuvent pas être obtenus avec cette fonction.

​

allow_hyperscan

Autorise les fonctions qui utilisent la bibliothèque Hyperscan. Désactivez cette option pour éviter des temps de compilation potentiellement longs et une consommation excessive de ressources.

​

allow_iceberg_remove_orphan_files

Permet d’utiliser ‘ALTER TABLE … EXECUTE remove_orphan_files()’ pour les tables Iceberg.

​

allow_insert_into_iceberg

Alias : allow_experimental_insert_into_iceberg

Autorise l’exécution de requêtes insert dans Iceberg.

​

allow_introspection_functions

Active ou désactive les fonctions d’introspection pour le profilage des requêtes.

Valeurs possibles :

• 1 — Fonctions d’introspection activées.
• 0 — Fonctions d’introspection désactivées.

Voir aussi

• Sampling Query Profiler
• Table système trace_log

​

allow_key_condition_coalesce_rewrite

Permet à la clé primaire MergeTree et aux skip indexes d’élaguer les granules pour les prédicats WHERE/PREWHERE qui utilisent coalesce ou ifNull. Sans ce paramètre, ces prédicats sont opaques pour l’analyse des index et ne permettent pas d’élagage, de sorte que des granules qui ne peuvent pas correspondre sont tout de même lus. Cela n’affecte que les granules lus ; les résultats de la requête restent inchangés, car les lignes sont toujours filtrées par le prédicat d’origine.

Deux formes de prédicats sont réécrites avant l’analyse des index :

• Une comparaison avec coalesce/ifNull, telle que coalesce(a, b) = 5, devient une disjonction afin qu’un index sur chaque argument puisse élaguer : a = 5 OR (a IS NULL AND b = 5), avec extension au cas de plusieurs arguments.
• Un coalesce/ifNull avec une constante par défaut falsy (zéro), utilisé directement comme condition, tel que ifNull(a = 5, 0) ou coalesce(a = 5, 0), est ramené à son prédicat interne a = 5. De tels wrappers ramènent le résultat à trois valeurs du prédicat interne à un booléen explicite (en faisant correspondre NULL à false).

​

allow_limit_by_partitions_independently

Activer l’évaluation indépendante de LIMIT BY pour chaque partition dans des threads distincts lorsque l’expression de partition est une fonction déterministe des colonnes de LIMIT BY.

​

allow_materialized_view_with_bad_select

Autorise CREATE MATERIALIZED VIEW avec une requête SELECT qui référence des tables ou des colonnes inexistantes. Elle doit toutefois rester syntaxiquement valide. Ne s’applique pas aux MV actualisables. Ne s’applique pas si le schéma de la MV doit être inféré à partir de la requête SELECT (c.-à-d. si le CREATE ne comporte ni liste de colonnes ni table TO). Peut être utilisé pour créer une MV avant sa table source.

​

allow_named_collection_override_by_default

Autorise par défaut la redéfinition des champs des collections nommées.

​

allow_non_metadata_alters

Autorise l’exécution d’opérations ALTER qui modifient non seulement les métadonnées des tables, mais aussi les données sur disque

​

allow_nonconst_timezone_arguments

Autorise les arguments de fuseau horaire non constants dans certaines fonctions liées à l’heure, comme toTimeZone(), fromUnixTimestamp*() et snowflakeToDateTime*(). Ce paramètre existe uniquement pour des raisons de compatibilité. Dans ClickHouse, le fuseau horaire est une propriété du type de données et, par conséquent, de la colonne. L’activation de ce paramètre donne à tort l’impression que différentes valeurs d’une même colonne peuvent avoir des fuseaux horaires différents. N’activez donc pas ce paramètre.

​

allow_nondeterministic_mutations

Paramètre défini au niveau de l’utilisateur qui autorise les mutations sur les tables répliquées à utiliser des fonctions non déterministes telles que dictGet.

Comme, par exemple, les dictionnaires peuvent ne pas être synchronisés entre les nœuds, les mutations qui en extraient des valeurs sont interdites par défaut sur les tables répliquées. L’activation de ce paramètre autorise ce comportement ; il incombe alors à l’utilisateur de veiller à ce que les données utilisées soient synchronisées sur l’ensemble des nœuds.

Exemple

<profiles>
    <default>
        <allow_nondeterministic_mutations>1</allow_nondeterministic_mutations>

        <!-- ... -->
    </default>

    <!-- ... -->

</profiles>

​

allow_nondeterministic_optimize_skip_unused_shards

Autorise les fonctions non déterministes (comme rand ou dictGet, ce dernier présentant certaines limitations lors des mises à jour) dans la clé de sharding.

Valeurs possibles :

• 0 — Interdit.
• 1 — Autorisé.

​

allow_nullable_tuple_in_extracted_subcolumns

Détermine si les sous-colonnes extraites de type Tuple(...) peuvent être typées comme Nullable(Tuple(...)).

• false : renvoie Tuple(...) et utilise les valeurs de tuple par défaut pour les lignes où la sous-colonne est absente.
• true : renvoie Nullable(Tuple(...)) et utilise NULL pour les lignes où la sous-colonne est absente.

Ce paramètre contrôle uniquement le comportement des sous-colonnes extraites. Il ne détermine pas si des colonnes Nullable(Tuple(...)) peuvent être créées dans des tables ; cela est contrôlé par enable_nullable_tuple_type.

ClickHouse utilise la valeur de ce paramètre chargée au démarrage du serveur. Les modifications effectuées avec SET ou SETTINGS au niveau de la requête ne modifient pas le comportement des sous-colonnes extraites. Pour modifier le comportement des sous-colonnes extraites, mettez à jour allow_nullable_tuple_in_extracted_subcolumns dans la configuration du profil de démarrage (par exemple, users.xml) et redémarrez le serveur.

​

allow_prefetched_read_pool_for_local_filesystem

Privilégie le pool de threads de prélecture si toutes les parts se trouvent sur le système de fichiers local

​

allow_prefetched_read_pool_for_remote_filesystem

Préférer le pool de threads de prélecture si toutes les part se trouvent sur un système de fichiers distant

​

allow_push_predicate_ast_for_distributed_subqueries

Autorise la propagation des prédicats au niveau de l’AST pour les sous-requêtes Distributed lorsque l’analyseur est activé

​

allow_push_predicate_when_subquery_contains_with

Autorise la propagation des prédicats lorsque la sous-requête contient une clause WITH

​

allow_rank_dense_rank_arguments

Autorise le passage d’arguments aux fonctions de fenêtre RANK et DENSE_RANK afin d’assurer la rétrocompatibilité.

Selon la norme SQL, RANK et DENSE_RANK ne prennent aucun argument : elles classent les lignes uniquement en fonction de la fenêtre OVER (ORDER BY ...). Dans les versions de ClickHouse antérieures à la 26.5, des requêtes comme RANK(x) OVER (...) acceptaient silencieusement l’argument et l’ignoraient, ce qui prêtait à confusion (la présence visible de l’argument laissait penser qu’il influençait le classement, alors que ce n’était pas le cas).

Lorsque ce paramètre est défini sur false (valeur par défaut), RANK et DENSE_RANK rejettent tout argument et lèvent NUMBER_OF_ARGUMENTS_DOESNT_MATCH. Lorsqu’il est défini sur true, le comportement permissif legacy est rétabli : les arguments sont silencieusement ignorés, comme avant la version 26.5.

​

allow_reorder_prewhere_conditions

Lors du déplacement des conditions de WHERE vers PREWHERE, autoriser leur réordonnancement pour optimiser le filtrage

​

allow_settings_after_format_in_insert

Indique si SETTINGS après FORMAT dans les requêtes INSERT est autorisé ou non. Il n’est pas recommandé d’utiliser ce paramètre, car une partie de SETTINGS peut être interprétée comme des valeurs.

Exemple :

INSERT INTO FUNCTION null('foo String') SETTINGS max_threads=1 VALUES ('bar');

Mais la requête suivante ne fonctionnera que si allow_settings_after_format_in_insert est activé :

SET allow_settings_after_format_in_insert=1;
INSERT INTO FUNCTION null('foo String') VALUES ('bar') SETTINGS max_threads=1;

Valeurs possibles :

• 0 — Interdire.
• 1 — Autoriser.

Utilisez ce paramètre uniquement pour assurer la rétrocompatibilité si vos cas d’usage dépendent de l’ancienne syntaxe.

​

allow_simdjson

Permet d’utiliser la bibliothèque simdjson dans les fonctions ‘JSON*’ si les instructions AVX2 sont disponibles. Si cette option est désactivée, rapidjson est utilisé.

​

allow_special_serialization_kinds_in_output_formats

Permet de produire des colonnes avec des modes de sérialisation spéciaux comme Sparse et Replicated sans les convertir en représentation complète de colonne. Cela permet d’éviter des copies de données inutiles lors du formatage.

​

allow_statistics

Alias : allow_experimental_statistics

Permet de définir des colonnes avec des statistiques et de gérer les statistiques.

​

allow_statistics_optimize

Alias : allow_statistic_optimize

Permet d’utiliser des statistiques pour optimiser les requêtes

​

allow_suspicious_codecs

S’il est défini sur true, autorise la spécification de codecs de compression dénués de sens.

​

allow_suspicious_fixed_string_types

Dans l’instruction CREATE TABLE, autorise la création de colonnes de type FixedString(n) avec n > 256. Un FixedString de longueur >= 256 est suspect et indique très probablement une mauvaise utilisation

​

allow_suspicious_indices

Rejette les index primaires/secondaires et les clés de tri ayant des expressions identiques

​

allow_suspicious_low_cardinality_types

Autorise ou restreint l’utilisation de LowCardinality avec des types de données de taille fixe inférieure ou égale à 8 octets : types de données numériques et FixedString(8_bytes_or_less).

Pour des valeurs fixes de petite taille, l’utilisation de LowCardinality est généralement inefficace, car ClickHouse stocke un index numérique pour chaque ligne. Par conséquent :

• L’utilisation de l’espace disque peut augmenter.
• La consommation de RAM peut être plus élevée, selon la taille du dictionnaire.
• Certaines fonctions peuvent être plus lentes en raison d’opérations supplémentaires d’encodage.

Les temps de fusion dans les tables du moteur MergeTree peuvent augmenter pour toutes les raisons décrites ci-dessus.

Valeurs possibles :

• 1 — L’utilisation de LowCardinality n’est pas restreinte.
• 0 — L’utilisation de LowCardinality est restreinte.

​

allow_suspicious_primary_key

Autoriser les PRIMARY KEY/ORDER BY jugés suspects pour MergeTree (c.-à-d. SimpleAggregateFunction).

​

allow_suspicious_ttl_expressions

Rejette les expressions TTL qui ne dépendent d’aucune colonne de la table. Cela signale le plus souvent une erreur utilisateur.

​

allow_suspicious_types_in_group_by

Autorise ou interdit l’utilisation des types Variant et Dynamic dans les clés GROUP BY.

​

allow_suspicious_types_in_order_by

Autorise ou restreint l’utilisation des types Variant et Dynamic dans les clés ORDER BY.

​

allow_suspicious_variant_types

Dans l’instruction CREATE TABLE, autorise la spécification du type Variant avec des types de variantes similaires (par exemple, différents types numériques ou de date). L’activation de ce paramètre peut introduire une certaine ambiguïté lors de la manipulation de valeurs de types similaires.

​

allow_unrestricted_reads_from_keeper

Autorise les lectures sans restriction (sans condition sur le chemin) depuis la table system.zookeeper ; cela peut être pratique, mais n’est pas sûr pour ZooKeeper

​

alter_move_to_space_execute_async

Exécuter ALTER TABLE MOVE … TO [DISK|VOLUME] de manière asynchrone

​

alter_partition_verbose_result

Active ou désactive l’affichage d’informations sur les parts auxquelles les opérations de manipulation de partitions et de parts ont été appliquées avec succès. S’applique à ATTACH PARTITION|PART et à FREEZE PARTITION.

Valeurs possibles :

• 0 — désactiver le mode verbeux.
• 1 — activer le mode verbeux.

Exemple

CREATE TABLE test(a Int64, d Date, s String) ENGINE = MergeTree PARTITION BY toYYYYMDECLARE(d) ORDER BY a;
INSERT INTO test VALUES(1, '2021-01-01', '');
INSERT INTO test VALUES(1, '2021-01-01', '');
ALTER TABLE test DETACH PARTITION ID '202101';

ALTER TABLE test ATTACH PARTITION ID '202101' SETTINGS alter_partition_verbose_result = 1;

┌─command_type─────┬─partition_id─┬─part_name────┬─old_part_name─┐
│ ATTACH PARTITION │ 202101       │ 202101_7_7_0 │ 202101_5_5_0  │
│ ATTACH PARTITION │ 202101       │ 202101_8_8_0 │ 202101_6_6_0  │
└──────────────────┴──────────────┴──────────────┴───────────────┘

ALTER TABLE test FREEZE SETTINGS alter_partition_verbose_result = 1;

┌─command_type─┬─partition_id─┬─part_name────┬─backup_name─┬─backup_path───────────────────┬─part_backup_path────────────────────────────────────────────┐
│ FREEZE ALL   │ 202101       │ 202101_7_7_0 │ 8           │ /var/lib/clickhouse/shadow/8/ │ /var/lib/clickhouse/shadow/8/data/default/test/202101_7_7_0 │
│ FREEZE ALL   │ 202101       │ 202101_8_8_0 │ 8           │ /var/lib/clickhouse/shadow/8/ │ /var/lib/clickhouse/shadow/8/data/default/test/202101_8_8_0 │
└──────────────┴──────────────┴──────────────┴─────────────┴───────────────────────────────┴─────────────────────────────────────────────────────────────┘

​

alter_sync

Alias : replication_alter_partitions_sync

Permet de définir le comportement d’attente pour les actions à exécuter sur les répliques par les requêtes ALTER, OPTIMIZE ou TRUNCATE.

Valeurs possibles :

• 0 — Ne pas attendre.
• 1 — Attendre l’exécution locale.
• 2 — Attendre toutes les répliques.
• 3 - Attendre uniquement les répliques actives.

Valeur par défaut dans Cloud : 0.

alter_sync s’applique uniquement aux tables Replicated et SharedMergeTree ; ce paramètre est sans effet sur les tables non Replicated ou Shared.

​

alter_update_mode

Mode des requêtes ALTER contenant des commandes UPDATE.

Valeurs possibles :

• heavy - exécute une mutation classique.
• lightweight - exécute une mise à jour légère si possible, sinon exécute une mutation classique.
• lightweight_force - exécute une mise à jour légère si possible, sinon lève une exception.

​

analyze_index_with_space_filling_curves

Si une table possède une courbe de remplissage de l’espace dans son index, par exemple ORDER BY mortonEncode(x, y) ou ORDER BY hilbertEncode(x, y), et si la requête comporte des conditions sur ses arguments, par exemple x >= 10 AND x <= 20 AND y >= 20 AND y <= 30, la courbe de remplissage de l’espace est utilisée pour l’analyse de l’index.

​

analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested

Permet d’ajouter à Nested des identifiants composés. Il s’agit d’un paramètre de compatibilité, car il modifie le résultat de la requête. Lorsqu’il est désactivé, SELECT a.b.c FROM table ARRAY JOIN a ne fonctionne pas, et SELECT a FROM table n’inclut pas la colonne a.b.c dans le résultat Nested a.

​

analyzer_compatibility_join_using_top_level_identifier

Force la résolution de l’identifiant dans JOIN USING à partir de la projection (par exemple, dans SELECT a + 1 AS b FROM t1 JOIN t2 USING (b), la jointure sera effectuée sur t1.a + 1 = t2.b, plutôt que sur t1.b = t2.b).

​

analyzer_compatibility_prefer_alias_over_subcolumn

Lorsqu’un identifiant multipartite comme b.id peut faire référence soit à la colonne id d’une table avec l’alias b, soit à une sous-colonne Tuple b.id d’une autre colonne, privilégiez l’interprétation avec préfixe d’alias (colonne id de b). Par défaut, le nouvel analyseur privilégie la sous-colonne. Activez ce paramètre pour retrouver la résolution de l’ancien analyseur.

​

analyzer_inline_views

Lorsqu’il est activé, l’analyseur remplace les vues ordinaires (non matérialisées, non paramétrées) par les sous-requêtes qui les définissent, ce qui permet des optimisations transversales comme le pushdown de prédicats et l’élagage des colonnes.

​

any_join_distinct_right_table_keys

Active le comportement legacy du serveur ClickHouse pour les opérations ANY INNER|LEFT JOIN.

Utilisez ce paramètre uniquement pour la rétrocompatibilité si vos cas d’usage dépendent du comportement legacy de JOIN.

Lorsque le comportement legacy est activé :

• Les résultats des opérations t1 ANY LEFT JOIN t2 et t2 ANY RIGHT JOIN t1 ne sont pas identiques, car ClickHouse utilise une logique de correspondance des clés de table de gauche à droite, de plusieurs vers une.
• Les résultats des opérations ANY INNER JOIN contiennent toutes les lignes de la table de gauche, comme dans les opérations SEMI LEFT JOIN.

Lorsque le comportement legacy est désactivé :

• Les résultats des opérations t1 ANY LEFT JOIN t2 et t2 ANY RIGHT JOIN t1 sont identiques, car ClickHouse utilise une logique qui assure une correspondance des clés de un vers plusieurs dans les opérations ANY RIGHT JOIN.
• Les résultats des opérations ANY INNER JOIN contiennent une ligne par clé provenant des tables de gauche et de droite.

Valeurs possibles :

• 0 — Le comportement legacy est désactivé.
• 1 — Le comportement legacy est activé.

Voir aussi :

• Strictness de JOIN

​

apply_deleted_mask

Permet de filtrer les lignes supprimées avec le DELETE léger. Si cette option est désactivée, une requête pourra lire ces lignes. Cela est utile pour le débogage et les scénarios de « restauration » de suppression

​

apply_mutations_on_fly

Si la valeur est true, les mutations (UPDATE et DELETE) qui ne sont pas matérialisées dans les data parts seront appliquées lors des SELECT.

​

apply_patch_parts

Si la valeur est true, les patch parts (qui représentent des mises à jour légères) sont appliquées lors des requêtes SELECT.

​

apply_patch_parts_join_cache_buckets

Le nombre de buckets dans le cache temporaire utilisé pour appliquer les patch parts en mode Join.

​

apply_prewhere_after_final

Lorsqu’il est activé, les conditions PREWHERE sont appliquées après le traitement FINAL pour ReplacingMergeTree et les moteurs similaires. Cela peut être utile lorsque PREWHERE fait référence à des colonnes dont les valeurs peuvent différer entre des lignes dupliquées, et que vous souhaitez que FINAL sélectionne la ligne retenue avant le filtrage. Lorsqu’il est désactivé, PREWHERE est appliqué lors de la lecture. Remarque : si apply_row_level_security_after_final est activé et que la politique de ligne utilise des colonnes qui ne font pas partie de la clé de tri, PREWHERE sera également différé afin de préserver le bon ordre d’exécution (la politique de ligne doit être appliquée avant PREWHERE).

​

apply_row_policy_after_final

Lorsqu’il est activé, les politiques de ligne et PREWHERE sont appliqués après le traitement FINAL pour les tables *MergeTree. (En particulier pour ReplacingMergeTree) Lorsqu’il est désactivé, les politiques de ligne sont appliquées avant FINAL, ce qui peut produire des résultats différents lorsque la politique filtre des lignes qui devraient être utilisées pour la déduplication dans ReplacingMergeTree ou des moteurs similaires.

Si l’expression de la politique de ligne dépend uniquement des colonnes de ORDER BY, elle sera tout de même appliquée avant FINAL à titre d’optimisation, car un tel filtrage ne peut pas affecter le résultat de la déduplication.

Valeurs possibles :

• 0 — La politique de ligne et PREWHERE sont appliqués avant FINAL (par défaut).
• 1 — La politique de ligne et PREWHERE sont appliqués après FINAL.

​

apply_settings_from_server

Indique si le client doit accepter les paramètres du serveur.

Cela n’affecte que les opérations effectuées côté client, en particulier l’analyse des données d’entrée INSERT et le formatage du résultat de la requête. La majeure partie de l’exécution des requêtes se fait sur le serveur et n’est pas affectée par ce paramètre.

Normalement, ce paramètre doit être défini dans le profil utilisateur (users.xml ou via des requêtes comme ALTER USER), et non via le client (arguments de ligne de commande du client, requête SET ou section SETTINGS d’une requête SELECT). Via le client, il peut être défini sur false, mais pas sur true (car le serveur n’enverra pas les paramètres si le profil utilisateur contient apply_settings_from_server = false).

Notez qu’au départ (24.12), il existait un paramètre serveur (send_settings_to_client), mais il a ensuite été remplacé par ce paramètre client, pour une meilleure ergonomie.

​

archive_adaptive_buffer_max_size_bytes

Limite la taille maximale du buffer adaptatif utilisé lors de l’écriture vers des fichiers d’archive (par exemple, des archives tar

​

arrow_flight_request_descriptor_type

Type de descripteur à utiliser pour les requêtes Arrow Flight. ‘path’ envoie le nom du jeu de données sous forme de descripteur de chemin. ‘command’ envoie une requête SQL sous forme de descripteur de commande (obligatoire pour Dremio).

Valeurs possibles :

• ‘path’ — Utilise FlightDescriptor::Path (par défaut, fonctionne avec la plupart des serveurs Arrow Flight)
• ‘command’ — Utilise FlightDescriptor::Command avec une requête SELECT (obligatoire pour Dremio)

​

ast_fuzzer_any_query

Lorsque la valeur est false (par défaut), le server-side AST fuzzer (contrôlé par ast_fuzzer_runs) ne soumet au fuzzing que les requêtes en lecture seule (SELECT, EXPLAIN, SHOW, DESCRIBE, EXISTS). Lorsque la valeur est true, tous les types de requêtes, y compris DDL et INSERT, sont soumis au fuzzing.

​

ast_fuzzer_runs

Active l’AST fuzzer côté serveur, qui exécute des requêtes aléatoires après chaque requête normale, sans conserver leurs résultats.

• 0 : désactivé (par défaut).
• Une valeur comprise entre 0 et 1 (exclusive) : probabilité d’exécuter une seule requête fuzzée.
• Une valeur >= 1 : nombre de requêtes fuzzées à exécuter par requête normale.

Le fuzzer accumule des fragments d’AST issus de toutes les requêtes de toutes les sessions, ce qui produit au fil du temps des mutations de plus en plus intéressantes. Les requêtes fuzzées qui échouent sont ignorées silencieusement ; leurs résultats ne sont jamais renvoyés au client.

​

asterisk_include_alias_columns

Inclure les colonnes ALIAS dans les requêtes avec caractère générique (SELECT *).

Valeurs possibles :

• 0 - désactivé
• 1 - activé

​

asterisk_include_materialized_columns

Inclut les colonnes MATERIALIZED dans les requêtes avec caractère générique (SELECT *).

Valeurs possibles :

• 0 - désactivé
• 1 - activé

​

asterisk_include_virtual_columns

Inclure les colonnes virtuelles dans les requêtes avec caractère générique (SELECT *).

Valeurs possibles :

• 0 - désactivé
• 1 - activé

​

async_insert

Si true, les données de la requête INSERT sont placées dans une file d’attente, puis écrites dans la table en arrière-plan. Si wait_for_async_insert est false, la requête INSERT est traitée presque instantanément ; sinon, le client attend que les données soient écrites dans la table.

​

async_insert_busy_timeout_decrease_rate

Le taux de croissance exponentielle selon lequel le délai d’expiration adaptatif de l’insertion asynchrone diminue

​

async_insert_busy_timeout_increase_rate

Le taux de croissance exponentielle selon lequel augmente le délai d’attente adaptatif des insertions asynchrones

​

async_insert_busy_timeout_max_ms

Alias : async_insert_busy_timeout_ms

Temps d’attente maximal avant de vider les données collectées pour chaque requête à partir de l’arrivée des premières données.

Valeur par défaut dans Cloud : 1000 (1s).

​

async_insert_busy_timeout_min_ms

Si l’ajustement automatique est activé via async_insert_use_adaptive_busy_timeout, durée minimale d’attente avant de vider les données collectées pour chaque requête à partir de l’arrivée des premières données. Elle sert également de valeur initiale pour l’algorithme adaptatif

​

async_insert_deduplicate

Pour les requêtes INSERT asynchrones dans une table répliquée, indique si la déduplication des blocs insérés doit être effectuée

​

async_insert_max_data_size

Taille maximale, en octets, des données non analysées accumulées pour chaque requête avant leur insertion

Valeur par défaut dans Cloud : 104857600 (100 MiB).

​

async_insert_max_query_number

Nombre maximal de requêtes d’insertion avant leur insertion. Ne prend effet que si le paramètre async_insert_deduplicate vaut 1.

​

async_insert_poll_timeout_ms

Délai d’expiration pour l’interrogation des données de la file d’attente des insertions asynchrones

​

async_insert_use_adaptive_busy_timeout

Si ce paramètre est défini sur true, le délai d’expiration d’activité adaptatif est utilisé pour les insertions asynchrones

​

async_query_sending_for_remote

Active la création asynchrone des connexions et l’envoi des requêtes lors de l’exécution d’une requête distante.

Activé par défaut.

​

async_socket_for_remote

Active la lecture asynchrone à partir du socket lors de l’exécution d’une requête distante.

Activé par défaut.

​

automatic_parallel_replicas_min_bytes_per_replica

Seuil d’octets à lire par réplique pour activer automatiquement les répliques parallèles (s’applique uniquement lorsque automatic_parallel_replicas_mode=1). 0 signifie qu’il n’y a pas de seuil. Le nombre total d’octets à lire est estimé à partir des statistiques collectées.

​

automatic_parallel_replicas_mode

Active le basculement automatique vers une exécution avec des répliques parallèles en fonction des statistiques collectées. Nécessite enable_analyzer = 1, enable_parallel_replicas != 0, parallel_replicas_local_plan = 1, ainsi que la définition de cluster_for_parallel_replicas. 0 - désactivé, 1 - activé, 2 - seule la collecte de statistiques est activée (le basculement vers une exécution avec des répliques parallèles est désactivé).

​

azure_allow_parallel_part_upload

Utilisez plusieurs threads pour le téléversement multipart sur Azure.

​

azure_check_objects_after_upload

Vérifie chaque objet téléversé dans le stockage Blob Azure afin de s’assurer que le téléversement a réussi

​

azure_connect_timeout_ms

Délai d’expiration de connexion à l’hôte pour les disques Azure.

​

azure_create_new_file_on_insert

Active ou désactive la création d’un nouveau fichier à chaque insertion dans les tables du moteur Azure

​

azure_ignore_file_doesnt_exist

Ignorer l’absence de fichier s’il n’existe pas lors de la lecture de certaines clés.

Valeurs possibles :

• 1 — SELECT renvoie un résultat vide.
• 0 — SELECT lève une exception.

​

azure_list_object_keys_size

Nombre maximal de fichiers pouvant être renvoyés par lot lors d’une requête ListObject

​

azure_max_blocks_in_multipart_upload

Nombre maximal de blocs dans un téléversement multipart pour Azure.

​

azure_max_get_burst

Nombre maximal de requêtes pouvant être envoyées simultanément avant d’atteindre la limite de requêtes par seconde. Par défaut (0), cette valeur est égale à azure_max_get_rps

​

azure_max_get_rps

Limite du nombre de requêtes GET Azure par seconde avant l’application du throttling. Zéro signifie aucune limite.

​

azure_max_inflight_parts_for_one_file

Le nombre maximal de parties chargées simultanément dans une requête de téléversement multipart. 0 signifie illimité.

​

azure_max_put_burst

Nombre maximal de requêtes pouvant être émises simultanément avant d’atteindre la limite de requêtes par seconde. Par défaut (0), il est égal à azure_max_put_rps

​

azure_max_put_rps

Limite du nombre de requêtes PUT Azure par seconde avant l’application d’une limitation du débit. Zéro signifie qu’il n’y a pas de limite.

​

azure_max_redirects

Nombre maximal de redirections Azure successives autorisées.

​

azure_max_single_part_copy_size

La taille maximale d’un objet pouvant être copié vers Azure blob storage au moyen d’une copie en une seule partie.

​

azure_max_single_part_upload_size

Taille maximale d’un objet pouvant être téléversé en une seule partie vers Azure blob storage.

​

azure_max_single_read_retries

Le nombre maximal de tentatives de nouvelle lecture unique depuis Azure Blob Storage.

​

azure_max_unexpected_write_error_retries

Le nombre maximal de nouvelles tentatives en cas d’erreurs inattendues lors de l’écriture dans Azure Blob Storage

​

azure_max_upload_part_size

La taille maximale d’une partie à téléverser lors d’un téléversement multipart vers Azure blob storage.

​

azure_min_upload_part_size

La taille minimale d’une partie à téléverser lors d’un téléversement multipart vers Azure Blob Storage.

​

azure_request_timeout_ms

Délai d’inactivité pour l’envoi et la réception de données vers/depuis azure. Échoue si un seul appel TCP de lecture ou d’écriture reste bloqué pendant ce délai.

​

azure_sdk_max_retries

Nombre maximal de réessais dans l’Azure SDK

​

azure_sdk_retry_initial_backoff_ms

Délai de backoff minimal entre les tentatives dans l’Azure SDK

​

azure_sdk_retry_max_backoff_ms

Délai de backoff maximal entre les tentatives dans azure sdk

​

azure_skip_empty_files

Active ou désactive la possibilité d’ignorer les fichiers vides dans le moteur S3.

Valeurs possibles :

• 0 — SELECT lève une exception si le fichier vide n’est pas compatible avec le format demandé.
• 1 — SELECT renvoie un résultat vide pour un fichier vide.

​

azure_strict_upload_part_size

La taille exacte de la partie à téléverser lors d’un téléversement multipart vers Azure blob storage.

​

azure_throw_on_zero_files_match

Lever une erreur si aucun fichier ne correspond aux règles d’expansion des motifs glob.

Valeurs possibles :

• 1 — SELECT lève une exception.
• 0 — SELECT renvoie un résultat vide.

​

azure_truncate_on_insert

Active ou désactive la suppression de toutes les données avant insertion dans les tables utilisant le moteur Azure.

​

azure_upload_part_size_multiply_factor

Multipliez azure_min_upload_part_size par ce facteur chaque fois que azure_multiply_parts_count_threshold parties ont été téléversées en une seule écriture vers Azure Blob Storage.

​

azure_upload_part_size_multiply_parts_count_threshold

Chaque fois que ce nombre de parties a été téléversé vers Azure blob storage, azure_min_upload_part_size est multiplié par azure_upload_part_size_multiply_factor.

​

azure_use_adaptive_timeouts

Lorsque cette option est définie sur true, les deux premières tentatives de toutes les requêtes Azure utilisent des délais d’expiration d’envoi et de réception courts. Lorsque cette option est définie sur false, toutes les tentatives utilisent des délais d’expiration identiques.

​

backup_restore_batch_size_for_keeper_multi

Taille maximale du lot pour une requête multiple adressée à [Zoo]Keeper lors d’une sauvegarde ou d’une restauration

​

backup_restore_batch_size_for_keeper_multiread

Taille maximale du lot pour une requête de lecture multiple vers [Zoo]Keeper lors d’une sauvegarde ou d’une restauration

​

backup_restore_failure_after_host_disconnected_for_seconds

Si, pendant une opération BACKUP ON CLUSTER ou RESTORE ON CLUSTER, un hôte ne recrée pas son nœud éphémère « alive » dans ZooKeeper dans ce délai, l’ensemble de la sauvegarde ou de la restauration est considéré comme échoué. Cette valeur doit être supérieure à tout délai raisonnable nécessaire à un hôte pour se reconnecter à ZooKeeper après une défaillance. Zéro signifie illimité.

​

backup_restore_finish_timeout_after_error_sec

Durée pendant laquelle l’initiateur doit attendre que les autres hôtes réagissent au nœud « error » et cessent de travailler sur l’opération BACKUP ON CLUSTER ou RESTORE ON CLUSTER en cours.

​

backup_restore_keeper_fault_injection_probability

Probabilité approximative d’échec d’une requête Keeper pendant la sauvegarde ou la restauration. La valeur valide est comprise dans l’intervalle [0.0f, 1.0f]

​

backup_restore_keeper_fault_injection_seed

0 - graine aléatoire ; sinon, la valeur du paramètre

​

backup_restore_keeper_max_retries

Nombre maximal de tentatives pour les opérations [Zoo]Keeper au cours d’une opération de sauvegarde ou de restauration. Doit être suffisamment élevé pour que l’opération complète n’échoue pas en raison d’une défaillance temporaire de [Zoo]Keeper.

​

backup_restore_keeper_max_retries_while_handling_error

Nombre maximal de nouvelles tentatives pour les opérations [Zoo]Keeper lors du traitement d’une erreur survenue pendant une opération BACKUP ON CLUSTER ou RESTORE ON CLUSTER.

​

backup_restore_keeper_max_retries_while_initializing

Nombre maximal de tentatives pour les opérations sur [Zoo]Keeper lors de l’initialisation d’une opération BACKUP ON CLUSTER ou RESTORE ON CLUSTER.

​

backup_restore_keeper_retry_initial_backoff_ms

Délai de backoff initial pour les opérations [Zoo]Keeper lors de la sauvegarde ou de la restauration

​

backup_restore_keeper_retry_max_backoff_ms

Délai maximal de backoff pour les opérations [Zoo]Keeper lors d’une sauvegarde ou d’une restauration

Valeur par défaut dans Cloud : 60000.

​

backup_restore_keeper_value_max_size

Taille maximale des données d’un nœud [Zoo]Keeper lors de la sauvegarde

​

backup_restore_s3_retry_attempts

Paramètre de Aws::Client::RetryStrategy, Aws::Client gère lui-même les tentatives de nouvelle exécution, 0 signifie aucune tentative. S’applique uniquement à la sauvegarde/restauration.

​

backup_restore_s3_retry_initial_backoff_ms

Délai de backoff initial en millisecondes avant la première nouvelle tentative lors d’une sauvegarde ou d’une restauration. Chaque nouvelle tentative suivante augmente ce délai de façon exponentielle, jusqu’au maximum spécifié par backup_restore_s3_retry_max_backoff_ms

​

backup_restore_s3_retry_jitter_factor

Facteur de gigue appliqué au délai de backoff des tentatives dans Aws::Client::RetryStrategy pendant les opérations de sauvegarde et de restauration. Le délai de backoff calculé est multiplié par un facteur aléatoire compris entre [1.0, 1.0 + jitter], jusqu’à la valeur maximale backup_restore_s3_retry_max_backoff_ms. Doit être compris dans l’intervalle [0.0, 1.0]

​

backup_restore_s3_retry_max_backoff_ms

Délai maximal, en millisecondes, entre deux tentatives lors des opérations de sauvegarde et de restauration.

​

backup_slow_all_threads_after_retryable_s3_error

Lorsqu’il est défini sur true, tous les threads exécutant des requêtes S3 vers le même endpoint de sauvegarde sont ralentis dès qu’une seule requête S3 rencontre une erreur S3 réessayable, telle que ‘Slow Down’. Lorsqu’il est défini sur false, chaque thread gère le backoff des requêtes S3 indépendamment des autres.

​

cache_warmer_threads

N’a d’effet que dans ClickHouse Cloud. Nombre de threads en arrière-plan utilisés pour télécharger de manière spéculative de nouvelles parties de données dans le cache du système de fichiers lorsque cache_populated_by_fetch est activé. Zéro pour désactiver.

​

calculate_text_stack_trace

Calcule une stack trace textuelle en cas d’exception pendant l’exécution d’une requête. Il s’agit du comportement par défaut. Cela nécessite une résolution de symboles, ce qui peut ralentir les tests de fuzzing lorsqu’un très grand nombre de requêtes erronées sont exécutées. En temps normal, vous ne devriez pas désactiver cette option.

​

cancel_http_readonly_queries_on_client_close

Annule les requêtes HTTP en lecture seule (par ex. SELECT) lorsqu’un client ferme la connexion sans attendre de réponse.

Valeur par défaut dans Cloud : 1.

​

cast_ipv4_ipv6_default_on_conversion_error

L’opérateur CAST vers IPv4, l’opérateur CAST vers le type IPv6, ainsi que les fonctions toIPv4 et toIPv6 renverront la valeur par défaut au lieu de lever une exception en cas d’erreur de conversion.

​

cast_keep_nullable

Active ou désactive la conservation du type de données Nullable dans les opérations CAST.

Lorsque ce paramètre est activé et que l’argument de la fonction CAST est Nullable, le résultat est lui aussi converti en type Nullable. Lorsque ce paramètre est désactivé, le résultat a toujours exactement le type de destination.

Valeurs possibles :

• 0 — Le résultat de CAST a exactement le type de destination spécifié.
• 1 — Si le type de l’argument est Nullable, le résultat de CAST est converti en Nullable(DestinationDataType).

Exemples

La requête suivante renvoie exactement le type de données de destination :

SET cast_keep_nullable = 0;
SELECT CAST(toNullable(toInt32(0)) AS Int32) as x, toTypeName(x);

Résultat :

┌─x─┬─toTypeName(CAST(toNullable(toInt32(0)), 'Int32'))─┐
│ 0 │ Int32                                             │
└───┴───────────────────────────────────────────────────┘

La requête suivante applique la modification Nullable au type de données de destination :

SET cast_keep_nullable = 1;
SELECT CAST(toNullable(toInt32(0)) AS Int32) as x, toTypeName(x);

Résultat :

┌─x─┬─toTypeName(CAST(toNullable(toInt32(0)), 'Int32'))─┐
│ 0 │ Nullable(Int32)                                   │
└───┴───────────────────────────────────────────────────┘

Voir aussi

• CAST fonctio

​

cast_string_to_date_time_mode

Permet de choisir un parseur pour la représentation textuelle de la date et de l’heure lors du cast depuis String.

Valeurs possibles :

• 'best_effort' — Active l’analyse étendue.

  ClickHouse peut analyser le format de base YYYY-MM-DD HH:MM:SS ainsi que tous les formats de date et d’heure ISO 8601. Par exemple, '2018-06-08T01:02:03.000Z'.

• 'best_effort_us' — Similaire à best_effort (voir la différence dans parseDateTimeBestEffortUS

• 'basic' — Utilise le parseur de base.

  ClickHouse peut analyser uniquement le format de base YYYY-MM-DD HH:MM:SS ou YYYY-MM-DD. Par exemple, 2019-08-20 10:18:56 ou 2019-08-20.

Voir aussi :

• Type de données DateTime.
• Fonctions de manipulation des dates et des heures.

​

cast_string_to_dynamic_use_inference

Utiliser l’inférence de types lors de la conversion de String en Dynamic

​

cast_string_to_variant_use_inference

Utiliser l’inférence de types lors de la conversion de String vers Variant.

​

check_named_collection_dependencies

Vérifie que DROP NAMED COLLECTION ne rendra pas inutilisables les tables qui en dépendent

​

check_query_single_value_result

Définit le niveau de détail du résultat de la requête CHECK TABLE pour les moteurs de la famille MergeTree .

Valeurs possibles :

• 0 — la requête affiche un statut de vérification pour chaque partie de données d’une table.
• 1 — la requête affiche le statut général de vérification de la table.

​

check_referential_table_dependencies

Vérifie qu’une requête DDL (telle que DROP TABLE ou RENAME) ne rompra pas les dépendances de référence

​

check_table_dependencies

Vérifie qu’une requête DDL (telle que DROP TABLE ou RENAME) n’interrompra pas les dépendances

​

checksum_on_read

Vérifie les sommes de contrôle à la lecture. Ce paramètre est activé par défaut et doit toujours l’être en production. Ne vous attendez à aucun bénéfice en le désactivant. Il ne doit être utilisé que pour des expériences et des benchmarks. Ce paramètre s’applique uniquement aux tables de la famille MergeTree. Les sommes de contrôle sont toujours vérifiées pour les autres moteurs de table et lors de la réception de données via le réseau.

​

cloud_mode

Mode Cloud

Valeur par défaut pour Cloud : 1.

​

cloud_mode_database_engine

Le moteur de base de données autorisé dans Cloud. 1 - réécrit les DDLs pour utiliser Replicated database, 2 - réécrit les DDLs pour utiliser Shared database

Valeur par défaut dans Cloud : 2.

​

cloud_mode_engine

La famille de moteurs autorisée dans Cloud.

• 0 - tout autoriser
• 1 - réécrire les DDLs pour utiliser *ReplicatedMergeTree
• 2 - réécrire les DDLs pour utiliser SharedMergeTree
• 3 - réécrire les DDLs pour utiliser SharedMergeTree, sauf lorsqu’un disk distant est explicitement spécifié
• 4 - identique à 3, mais utilise en plus Alias au lieu de Distributed (la table Alias pointera vers la table de destination de la table Distributed et utilisera donc la table locale correspondante)

UInt64 pour réduire au minimum la partie publique

Valeur par défaut dans Cloud : 2.

​

cluster_for_parallel_replicas

Cluster du segment où se trouve le serveur actuel

Valeur par défaut Cloud : default.

​

cluster_function_process_archive_on_multiple_nodes

Si cette option est définie sur true, les performances du traitement des archives dans les fonctions de cluster sont améliorées. Elle doit être définie sur false pour garantir la compatibilité et éviter les erreurs lors de la mise à niveau vers la version 25.7 ou ultérieure si vous utilisez des fonctions de cluster avec des archives sur des versions antérieures.

​

cluster_table_function_buckets_batch_size

Définit la taille approximative d’un lot (en octets) utilisé pour le traitement distribué des tâches dans les fonctions de table de cluster avec une granularité de découpage bucket. Le système accumule les données jusqu’à ce qu’au moins ce volume soit atteint. La taille réelle peut être légèrement supérieure afin de respecter les limites des données.

​

cluster_table_function_split_granularity

Contrôle la façon dont les données sont découpées en tâches lors de l’exécution d’une CLUSTER TABLE FUNCTION.

Ce paramètre définit la granularité de la distribution du travail dans le cluster :

• file — chaque tâche traite un fichier entier.
• bucket — des tâches sont créées pour chaque bloc de données interne au sein d’un fichier (par exemple, les groupes de lignes Parquet).

Choisir une granularité plus fine (comme bucket) peut améliorer le parallélisme lorsque vous travaillez avec un petit nombre de gros fichiers. Par exemple, si un fichier Parquet contient plusieurs groupes de lignes, l’activation de la granularité bucket permet de traiter chaque groupe indépendamment par différents workers.

​

collect_hash_table_stats_during_aggregation

Active la collecte des statistiques de la table de hachage afin d’optimiser l’allocatio

​

collect_hash_table_stats_during_joins

Activer la collecte de statistiques sur la table de hachage afin d’optimiser l’allocation de mémoire

​

compatibility

Le paramètre compatibility indique à ClickHouse d’utiliser les paramètres par défaut d’une version antérieure de ClickHouse, cette version étant fournie comme valeur du paramètre.

Si certains paramètres ont des valeurs autres que les valeurs par défaut, ces valeurs sont conservées (seuls les paramètres qui n’ont pas été modifiés sont affectés par le paramètre compatibility).

Ce paramètre prend comme valeur un numéro de version de ClickHouse sous forme de chaîne, par exemple 22.3 ou 22.8. Une valeur vide signifie que ce paramètre est désactivé.

Désactivé par défaut.

Dans ClickHouse Cloud, le paramètre de compatibilité par défaut au niveau du service doit être défini par le support ClickHouse Cloud. Veuillez ouvrir un ticket pour le faire configurer. Toutefois, le paramètre compatibility peut être redéfini au niveau de l’utilisateur, du rôle, du profil, de la query ou de la session à l’aide des mécanismes standard de configuration de ClickHouse, par exemple SET compatibility = '22.3' dans une session ou SETTINGS compatibility = '22.3' dans une query.

​

compatibility_ignore_auto_increment_in_create_table

Ignore le mot-clé AUTO_INCREMENT dans la déclaration de colonne si la valeur est true, sinon renvoie une erreur. Cela simplifie la migration depuis MySQL

​

compatibility_ignore_collation_in_create_table

Compatibilité : ignorer la collation lors de CREATE TABLE

​

compatibility_s3_presigned_url_query_in_path

Compatibilité : lorsqu’elle est activée, les paramètres de requête d’une URL pré-signée (par ex. X-Amz-*) sont incorporés à la clé S3 (comportement legacy), de sorte que « ? » agit comme un caractère générique dans le chemin. Lorsqu’elle est désactivée (par défaut), les paramètres de requête d’une URL pré-signée sont conservés dans la chaîne de requête de l’URL afin d’éviter d’interpréter « ? » comme un caractère générique.

​

compile_aggregate_expressions

Active ou désactive la compilation JIT des fonctions d’agrégation en code natif. L’activation de ce paramètre peut améliorer les performances.

Valeurs possibles :

• 0 — L’agrégation s’effectue sans compilation JIT.
• 1 — L’agrégation s’effectue avec compilation JIT.

Voir aussi

• min_count_to_compile_aggregate_expression

​

compile_expressions

Compile une partie des fonctions scalaires et des opérateurs en code natif.

​

compile_sort_description

Compile la description de tri en code natif.

​

connect_timeout

Délai d’expiration de connexion en l’absence de répliques.

​

connect_timeout_with_failover_ms

Délai d’attente, en millisecondes, pour établir une connexion à un serveur distant avec un moteur de table Distributed, si les sections ‘shard’ et ‘replica’ sont utilisées dans la définition du cluster. En cas d’échec, plusieurs tentatives sont effectuées pour se connecter à différentes répliques.

​

connect_timeout_with_failover_secure_ms

Délai d’expiration de la connexion lors de la sélection de la première réplique saine (pour les connexions sécurisées).

​

connection_pool_max_wait_ms

Le temps d’attente, en millisecondes, d’une connexion lorsque le pool de connexions est saturé.

Valeurs possibles :

• Entier positif.
• 0 — délai d’expiration infini.

​

connections_with_failover_max_tries

Nombre maximal de tentatives de connexion à chaque réplique pour le moteur de table Distributed.

​

convert_query_to_cnf

Lorsqu’il est défini sur true, une requête SELECT est convertie en forme normale conjonctive (CNF). Dans certains cas, la réécriture d’une requête en CNF peut s’exécuter plus rapidement (consultez cette issue GitHub pour plus d’explications).

Par exemple, notez que la requête SELECT suivante n’est pas modifiée (comportement par défaut) :

EXPLAIN SYNTAX
SELECT *
FROM
(
    SELECT number AS x
    FROM numbers(20)
) AS a
WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15))
SETTINGS convert_query_to_cnf = false;

Le résultat est :

┌─explain────────────────────────────────────────────────────────┐
│ SELECT x                                                       │
│ FROM                                                           │
│ (                                                              │
│     SELECT number AS x                                         │
│     FROM numbers(20)                                           │
│     WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15)) │
│ ) AS a                                                         │
│ WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15))     │
│ SETTINGS convert_query_to_cnf = 0                              │
└────────────────────────────────────────────────────────────────┘

Définissons convert_query_to_cnf à true et voyons ce qui change :

EXPLAIN SYNTAX
SELECT *
FROM
(
    SELECT number AS x
    FROM numbers(20)
) AS a
WHERE ((x >= 1) AND (x <= 5)) OR ((x >= 10) AND (x <= 15))
SETTINGS convert_query_to_cnf = true;

Notez que la clause WHERE est réécrite en FNC, mais le jeu de résultats reste identique - la logique booléenne est inchangée :

┌─explain───────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ SELECT x                                                                                                              │
│ FROM                                                                                                                  │
│ (                                                                                                                     │
│     SELECT number AS x                                                                                                │
│     FROM numbers(20)                                                                                                  │
│     WHERE ((x <= 15) OR (x <= 5)) AND ((x <= 15) OR (x >= 1)) AND ((x >= 10) OR (x <= 5)) AND ((x >= 10) OR (x >= 1)) │
│ ) AS a                                                                                                                │
│ WHERE ((x >= 10) OR (x >= 1)) AND ((x >= 10) OR (x <= 5)) AND ((x <= 15) OR (x >= 1)) AND ((x <= 15) OR (x <= 5))     │
│ SETTINGS convert_query_to_cnf = 1                                                                                     │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Valeurs possibles : true, false

​

correlated_subqueries_default_join_kind

Contrôle le type de JOIN utilisé dans le plan de requête décorrélé. La valeur par défaut est right, ce qui signifie que le plan décorrélé contiendra des RIGHT JOIN avec la sous-requête en entrée du côté droit.

Valeurs possibles :

• left - Le processus de décorrélation produira des LEFT JOIN et la table d’entrée apparaîtra du côté gauche.
• right - Le processus de décorrélation produira des RIGHT JOIN et la table d’entrée apparaîtra du côté droit.

​

correlated_subqueries_substitute_equivalent_expressions

Utilisez des expressions de filtre pour déduire des expressions équivalentes et les substituer plutôt que de créer un CROSS JOIN.

​

correlated_subqueries_use_in_memory_buffer

Utilise un tampon en mémoire pour l’entrée des sous-requêtes corrélées afin d’éviter leur réévaluation.

​

count_distinct_implementation

Indique laquelle des fonctions uniq* doit être utilisée pour effectuer l’opération COUNT(DISTINCT …).

Valeurs possibles :

• uniq
• uniqCombined
• uniqCombined64
• uniqHLL12
• uniqExact

​

count_distinct_optimization

Réécrire count distinct en sous-requête avec group by

​

count_matches_stop_at_empty_match

Interrompt le comptage dès qu’un motif correspond à une chaîne vide dans la fonction countMatches.

​

create_if_not_exists

Active par défaut IF NOT EXISTS pour l’instruction CREATE. Si ce paramètre ou IF NOT EXISTS est spécifié et qu’une table portant ce nom existe déjà, aucune exception n’est levée.

​

create_index_ignore_unique

Ignore le mot-clé UNIQUE dans CREATE UNIQUE INDEX. Prévu pour les tests de compatibilité SQL.

​

create_replicated_merge_tree_fault_injection_probability

La probabilité d’une injection de fautes lors de la création d’une table, après la création des métadonnées dans ZooKeeper

​

create_table_empty_primary_key_by_default

Autorise la création de tables *MergeTree avec une clé primaire vide lorsque ORDER BY et PRIMARY KEY ne sont pas spécifiés

​

cross_join_min_bytes_to_compress

Taille minimale du bloc à compresser dans un CROSS JOIN. Une valeur de zéro signifie que ce seuil est désactivé. Le bloc est compressé dès que l’un des deux seuils (en lignes ou en octets) est atteint.

​

cross_join_min_rows_to_compress

Nombre minimal de lignes à partir duquel compresser le bloc dans un CROSS JOIN. Une valeur nulle signifie la désactivation de ce seuil. Ce bloc est compressé dès que l’un des deux seuils (en lignes ou en octets) est atteint.

​

cross_to_inner_join_rewrite

Utilisez un INNER JOIN au lieu d’une jointure par virgule/CROSS JOIN s’il existe des expressions de jointure dans la clause WHERE. Valeurs : 0 - aucune réécriture, 1 - appliquer si possible aux jointures par virgule/CROSS JOIN, 2 - forcer la réécriture de toutes les jointures par virgule, CROSS - si possible

​

data_type_default_nullable

Permet aux types de données sans modificateurs explicites NULL or NOT NULL dans la définition d’une colonne d’être Nullable.

Valeurs possibles :

• 1 — Les types de données dans les définitions de colonnes sont Nullable par défaut.
• 0 — Les types de données dans les définitions de colonnes ne sont pas Nullable par défaut.

​

database_atomic_wait_for_drop_and_detach_synchronously

Ajoute un modificateur SYNC à toutes les requêtes DROP et DETACH.

Valeurs possibles :

• 0 — Les requêtes seront exécutées avec un délai.
• 1 — Les requêtes seront exécutées sans délai.

​

database_datalake_require_metadata_access

Indique s’il faut lever une erreur ou non si l’on ne dispose pas des droits nécessaires pour obtenir les métadonnées de la table dans le moteur de base de données DataLakeCatalog.

​

database_replicated_allow_explicit_uuid

0 - Ne pas autoriser la spécification explicite des UUID pour les tables dans les bases de données Replicated. 1 - Autoriser. 2 - Autoriser, mais ignorer l’UUID spécifié et en générer un aléatoire à la place.

​

database_replicated_allow_heavy_create

Autorise les requêtes DDL de longue durée (CREATE AS SELECT et POPULATE) avec le moteur de base de données Replicated. Notez que cela peut bloquer la file d’attente DDL pendant longtemps.

​

database_replicated_allow_only_replicated_engine

Autorise la création uniquement de tables Replicated dans une base de données utilisant le moteur Replicated

Cloud default value: 1.

​

database_replicated_allow_replicated_engine_arguments

0 - Ne permet pas de spécifier explicitement le chemin ZooKeeper ni le nom de réplique pour les tables *MergeTree dans les bases de données Replicated. 1 - Autoriser. 2 - Autoriser, mais ignorer le chemin spécifié et utiliser le chemin par défaut à la place. 3 - Autoriser et ne pas consigner d’avertissement.

​

database_replicated_always_detach_permanently

Exécute DETACH TABLE en tant que DETACH TABLE PERMANENTLY si le moteur de base de données est Replicated

​

database_replicated_enforce_synchronous_settings

Force l’attente synchrone pour certaines requêtes (voir aussi database_atomic_wait_for_drop_and_detach_synchronously, mutations_sync, alter_sync). Il n’est pas recommandé d’activer ces paramètres.

​

database_replicated_initial_query_timeout_sec

Définit, en secondes, la durée pendant laquelle la requête DDL initiale doit attendre que la base de données Replicated traite les entrées précédentes de la file d’attente DDL.

Valeurs possibles :

• Entier positif.
• 0 — Illimité.

​

database_shared_drop_table_delay_seconds

Le délai, en secondes, avant qu’une table supprimée ne soit effectivement retirée d’une base de données Shared. Cela permet de la récupérer pendant ce délai à l’aide de l’instruction UNDROP TABLE.

​

decimal_check_overflow

Contrôle le dépassement de capacité lors des opérations arithmétiques et de comparaison sur les nombres décimaux

​

deduplicate_blocks_in_dependent_materialized_views

Active ou désactive la vérification de déduplication pour les vues matérialisées qui reçoivent des données de tables Replicated*.

Valeurs possibles :

0 — Désactivé. 1 — Activé.

Lorsqu’il est activé, ClickHouse effectue la déduplication des blocs dans les vues matérialisées qui dépendent de tables Replicated*. Ce paramètre est utile pour garantir que les vues matérialisées ne contiennent pas de doublons lorsque l’opération d’insertion est retentée à la suite d’un échec.

Voir aussi

• Traitement de NULL dans les opérateurs IN

​

deduplicate_insert

Active ou désactive la déduplication des blocs de INSERT INTO (pour les tables Replicated*). Ce paramètre remplace les paramètres insert_deduplicate et async_insert_deduplicate. Ce paramètre a trois valeurs possibles :

• disable — La déduplication est désactivée pour la requête INSERT INTO.
• enable — La déduplication est activée pour la requête INSERT INTO.
• backward_compatible_choice — La déduplication est activée si insert_deduplicate ou async_insert_deduplicate sont activés pour le type d’insert concerné.

​

deduplicate_insert_select

Active ou désactive la déduplication de blocs pour INSERT SELECT (sur les tables Replicated*). Ce paramètre remplace insert_deduplicate et deduplicate_insert pour les requêtes INSERT SELECT. Ce paramètre a quatre valeurs possibles :

• disable — La déduplication est désactivée pour la requête INSERT SELECT.
• force_enable — La déduplication est activée pour la requête INSERT SELECT. Si le résultat du SELECT n’est pas stable, une exception est levée.
• enable_when_possible — La déduplication est activée si insert_deduplicate est activé et si le résultat du SELECT est stable, sinon elle est désactivée.
• enable_even_for_bad_queries - La déduplication est activée si insert_deduplicate est activé. Si le résultat du SELECT n’est pas stable, un avertissement est journalisé, mais la requête est exécutée avec déduplication. Cette option est conservée pour la rétrocompatibilité. Envisagez plutôt d’utiliser d’autres options, car elle peut entraîner des résultats inattendus.

​

default_materialized_view_sql_security

Permet de définir la valeur par défaut de l’option SQL SECURITY lors de la création d’une vue matérialisée. En savoir plus sur sécurité SQL.

La valeur par défaut est DEFINER.

​

default_max_bytes_in_join

Taille maximale de la table de droite si une limite est requise mais que max_bytes_in_join n’est pas défini.

​

default_normal_view_sql_security

Permet de définir l’option SQL SECURITY par défaut lors de la création d’une vue normale. En savoir plus sur la sécurité SQL.

La valeur par défaut est INVOKER.

​

default_table_engine

Moteur de table par défaut à utiliser lorsque ENGINE n’est pas défini dans une instruction CREATE.

Valeurs possibles :

• une chaîne représentant n’importe quel nom de moteur de table valide

Valeur par défaut dans Cloud : SharedMergeTree.

Exemple

Requête :

SET default_table_engine = 'Log';

SELECT name, value, changed FROM system.settings WHERE name = 'default_table_engine';

Résultat :

┌─name─────────────────┬─value─┬─changed─┐
│ default_table_engine │ Log   │       1 │
└──────────────────────┴───────┴─────────┘

Dans cet exemple, toute nouvelle table qui ne précise pas d’Engine utilisera le moteur de table Log :

Requête :

CREATE TABLE my_table (
    x UInt32,
    y UInt32
);

SHOW CREATE TABLE my_table;

Résultat :

┌─statement────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.my_table
(
    `x` UInt32,
    `y` UInt32
)
ENGINE = Log
└──────────────────────────────────────────────────────────────────────────┘

​

default_temporary_table_engine

Identique à default_table_engine, mais pour les tables temporaires.

Dans cet exemple, toute nouvelle table temporaire qui ne précise pas d’Engine utilisera le moteur de table Log :

Requête :

SET default_temporary_table_engine = 'Log';

CREATE TEMPORARY TABLE my_table (
    x UInt32,
    y UInt32
);

SHOW CREATE TEMPORARY TABLE my_table;

Résultat :

┌─statement────────────────────────────────────────────────────────────────┐
│ CREATE TEMPORARY TABLE default.my_table
(
    `x` UInt32,
    `y` UInt32
)
ENGINE = Log
└──────────────────────────────────────────────────────────────────────────┘

​

default_view_definer

Permet de définir l’option DEFINER par défaut lors de la création d’une vue. En savoir plus sur la sécurité SQL.

La valeur par défaut est CURRENT_USER.

​

defer_partition_pruning_after_final

Lorsqu’il est activé (par défaut), l’élagage des partitions est ignoré pour les requêtes FINAL sur les tables dont les colonnes de clé de partition ne font pas partie de la clé de tri. Il s’agit du comportement sans risque pour la correction introduit dans la version 26.3 : FINAL peut avoir besoin de dédupliquer des lignes qui partagent une clé primaire mais se trouvent dans des partitions différentes, et l’élagage des partitions exclurait alors silencieusement ces lignes du jeu de données soumis à la déduplication.

Lorsqu’il est désactivé, l’élagage des partitions est appliqué même avec FINAL, ce qui rétablit le comportement antérieur à 26.3. Cela peut être nettement plus rapide pour les requêtes avec des prédicats WHERE sur la colonne de partition, mais cela n’est correct que lorsque des lignes ayant la même clé primaire ne peuvent pas exister dans des partitions différentes — par exemple, les tables de journaux d’événements dont la colonne de partition est définie au moment de l’insertion et ne change jamais.

Ce paramètre n’affecte que les tables partitionnées dont les colonnes de clé de partition ne sont pas incluses dans la clé de tri ; pour les autres tables, l’élagage des partitions est toujours appliqué.

Valeurs possibles :

• 0 — Appliquer l’élagage des partitions avant FINAL (comportement antérieur à 26.3, plus rapide mais non sûr dans le cas général).
• 1 — Reporter l’élagage des partitions après FINAL (par défaut, sans risque pour la correction).

​

delta_lake_enable_engine_predicate

Active l’élagage interne des données dans delta-kernel.

​

delta_lake_enable_expression_visitor_logging

Active les logs de niveau Test du visiteur d’expressions de DeltaLake. Ces logs peuvent être trop verbeux, même pour une journalisation de test.

​

delta_lake_insert_max_bytes_in_data_file

Définit la taille maximale, en octets, d’un fichier de données inséré dans Delta Lake.

​

delta_lake_insert_max_rows_in_data_file

Définit le nombre maximal de lignes pour un seul fichier de données inséré dans Delta Lake.

​

delta_lake_log_metadata

Active la journalisation des fichiers de métadonnées Delta Lake dans la table système.

​

delta_lake_reload_schema_for_consistency

S’il est activé, le schéma est rechargé à partir des métadonnées de DeltaLake avant l’exécution de chaque requête afin de garantir la cohérence entre le schéma utilisé lors de l’analyse de la requête et le schéma utilisé lors de l’exécution.

​

delta_lake_snapshot_end_version

Version de fin de l’instantané Delta Lake à lire. La valeur -1 signifie qu’il faut lire la dernière version (la valeur 0 est une version d’instantané valide).

​

delta_lake_snapshot_start_version

Version initiale de l’instantané Delta Lake à lire. La valeur -1 signifie qu’il faut lire la dernière version (la valeur 0 est une version d’instantané valide).

​

delta_lake_snapshot_version

Version de l’instantané Delta Lake à lire. La valeur -1 indique qu’il faut lire la version la plus récente (0 est une version d’instantané valide).

​

delta_lake_throw_on_engine_predicate_error

Active la levée d’une exception en cas d’erreur lors de l’analyse du prédicat de scan dans delta-kernel.

​

describe_compact_output

Si true, inclut uniquement les noms et les types de colonnes dans le résultat de la requête DESCRIBE

​

describe_include_subcolumns

Permet de décrire les sous-colonnes dans une requête DESCRIBE. Par exemple, les membres d’un Tuple ou les sous-colonnes d’un type de données Map, Nullable ou Array.

Valeurs possibles :

• 0 — Les sous-colonnes ne sont pas incluses dans les requêtes DESCRIBE.
• 1 — Les sous-colonnes sont incluses dans les requêtes DESCRIBE.

Exemple

Voir un exemple de l’instruction DESCRIBE.

​

describe_include_virtual_columns

Si true, les colonnes virtuelles de la table seront incluses dans le résultat de la requête DESCRIBE

​

dialecte

Dialecte utilisé pour analyser la requête

​

dictionary_use_async_executor

Exécute un pipeline de lecture de la source du dictionnaire sur plusieurs threads. Pris en charge uniquement par les dictionnaires avec une source CLICKHOUSE locale.

​

dictionary_validate_primary_key_type

Valider le type de clé primaire pour les dictionnaires. Par défaut, le type de l’ID des layouts simples est converti implicitement en UInt64.

​

distinct_overflow_mode

Définit ce qui se passe lorsque la quantité de données dépasse l’une des limites.

Valeurs possibles :

• throw : lever une exception (par défaut).
• break : arrêter l’exécution de la requête et renvoyer un résultat partiel, comme si les données source étaient épuisées.

​

distributed_aggregation_memory_efficient

Indique si le mode d’agrégation distribuée économe en mémoire est activé.

​

distributed_background_insert_batch

Aliases : distributed_directory_monitor_batch_inserts

Active ou désactive l’envoi par lots des données insérées.

Lorsque l’envoi par lots est activé, le moteur de table Distributed tente d’envoyer plusieurs fichiers de données insérées en une seule opération au lieu de les envoyer séparément. L’envoi par lots améliore les performances du cluster en exploitant plus efficacement les ressources du serveur et du réseau.

Valeurs possibles :

• 1 — Activé.
• 0 — Désactivé.

​

distributed_background_insert_max_sleep_time_ms

Alias : distributed_directory_monitor_max_sleep_time_ms

Intervalle maximal permettant au moteur de table Distributed d’envoyer des données. Limite la croissance exponentielle de l’intervalle défini dans le réglage distributed_background_insert_sleep_time_ms.

Valeurs possibles :

• Un nombre entier positif de millisecondes.

​

distributed_background_insert_sleep_time_ms

Alias : distributed_directory_monitor_sleep_time_ms

Intervalle de base du moteur de table Distributed pour l’envoi des données. L’intervalle réel augmente de façon exponentielle en cas d’erreur.

Valeurs possibles :

• Un nombre entier positif de millisecondes.

​

distributed_background_insert_split_batch_on_failure

Alias : distributed_directory_monitor_split_batch_on_failure

Active ou désactive le fractionnement des batches en cas d’échec.

Il peut arriver que l’envoi d’un batch donné vers le shard distant échoue à cause d’un pipeline en aval complexe (par ex. MATERIALIZED VIEW avec GROUP BY), en raison de Memory limit exceeded ou d’erreurs similaires. Dans ce cas, réessayer ne servira à rien (et bloquera les envois distribués pour la table), tandis que l’envoi des fichiers de ce batch un par un peut permettre à INSERT de réussir.

Ainsi, définir ce paramètre sur 1 désactive le batching pour ces batches (c.-à-d. désactive temporairement distributed_background_insert_batch pour les batches en échec).

Valeurs possibles :

• 1 — Activé.
• 0 — Désactivé.

Ce paramètre affecte également les batches corrompus (qui peuvent apparaître à la suite d’un arrêt anormal du serveur (machine) et de l’absence de fsync_after_insert/fsync_directories pour le moteur de table Distributed).

Vous ne devez pas vous reposer sur le fractionnement automatique des batches, car cela peut nuire aux performances.

​

distributed_background_insert_timeout

Alias : insert_distributed_timeout

Délai d’expiration de la requête d’insert dans Distributed. Ce paramètre est utilisé uniquement lorsque insert_distributed_sync est activé. Une valeur de 0 signifie qu’il n’y a pas de délai d’expiration.

​

distributed_cache_alignment

N’a d’effet que dans ClickHouse Cloud. Paramètre réservé aux tests, ne le modifiez pas

​

distributed_cache_bypass_connection_pool

N’a d’effet que dans ClickHouse Cloud. Permet de contourner le pool de connexions du cache distribué

​

distributed_cache_connect_backoff_max_ms

N’a d’effet que dans ClickHouse Cloud. Délai de backoff maximal, en millisecondes, pour la création de connexions au cache distribué.

​

distributed_cache_connect_backoff_min_ms

N’a d’effet que dans ClickHouse Cloud. Délai minimal de backoff, en millisecondes, pour la création de connexions au cache distribué.

​

distributed_cache_connect_max_tries

N’a d’effet que dans ClickHouse Cloud. Nombre de tentatives de connexion au cache distribué en cas d’échec

​

distributed_cache_connect_timeout_ms

N’a d’effet que dans ClickHouse Cloud. Délai d’expiration de connexion lors de l’établissement d’une connexion au serveur cache distribué.

​

distributed_cache_credentials_refresh_period_seconds

N’a d’effet que dans ClickHouse Cloud. Période de rafraîchissement des identifiants d’authentification.

​

distributed_cache_data_packet_ack_window

N’a d’effet que dans ClickHouse Cloud. Fenêtre d’envoi des ACK pour la séquence DataPacket au sein d’une même requête de lecture du cache distribué

​

distributed_cache_discard_connection_if_unread_data

N’a d’effet que dans ClickHouse Cloud. Interrompt la connexion si certaines données n’ont pas été lues.

​

distributed_cache_fetch_metrics_only_from_current_az

Ne prend effet que dans ClickHouse Cloud. Récupère les métriques uniquement depuis la zone de disponibilité actuelle dans system.distributed_cache_metrics, system.distributed_cache_events

​

distributed_cache_file_cache_name

N’a d’effet que dans ClickHouse Cloud. Paramètre utilisé uniquement pour les tests CI : nom du cache du système de fichiers à utiliser pour le cache distribué.

​

distributed_cache_log_mode

N’a d’effet que dans ClickHouse Cloud. Mode d’écriture dans system.distributed_cache_log

​

distributed_cache_max_unacked_inflight_packets

N’a d’effet que dans ClickHouse Cloud. Nombre maximal de paquets en transit non acquittés dans une même requête de lecture du cache distribué

​

distributed_cache_min_bytes_for_seek

N’a d’effet que dans ClickHouse Cloud. Nombre minimal d’octets à partir duquel effectuer un seek dans le cache distribué.

​

distributed_cache_pool_behaviour_on_limit

N’a d’effet que dans ClickHouse Cloud. Définit le comportement de la connexion du cache distribué lorsque la limite du pool est atteinte

​

distributed_cache_prefer_bigger_buffer_size

N’a d’effet que dans ClickHouse Cloud. Identique à filesystem_cache_prefer_bigger_buffer_size, mais pour le cache distribué.

​

distributed_cache_read_only_from_current_az

N’a d’effet que dans ClickHouse Cloud. Permet de lire uniquement depuis la zone de disponibilité actuelle. Si ce paramètre est désactivé, la lecture s’effectue depuis tous les serveurs de cache de toutes les zones de disponibilité.

​

distributed_cache_read_request_max_tries

N’a d’effet que dans ClickHouse Cloud. Nombre de tentatives pour effectuer une requête de lecture au cache distribué en cas d’échec

​

distributed_cache_receive_response_wait_milliseconds

N’a d’effet que dans ClickHouse Cloud. Délai d’attente, en millisecondes, pour recevoir les données d’une requête depuis le cache distribué

​

distributed_cache_receive_timeout_milliseconds

N’a d’effet que dans ClickHouse Cloud. Délai d’attente, en millisecondes, pour recevoir tout type de réponse du cache distribué

Valeur par défaut dans Cloud : 20000.

​

distributed_cache_receive_timeout_ms

N’a d’effet que dans ClickHouse Cloud. Délai d’attente, en millisecondes, pour recevoir des données du serveur cache distribué. Si aucun octet n’est reçu pendant cet intervalle, une exception est levée.

​

distributed_cache_send_timeout_ms

N’a d’effet que dans ClickHouse Cloud. Délai d’expiration, en millisecondes, pour l’envoi de données au serveur de cache distribué. Si un client doit envoyer des données mais ne parvient pas à transmettre le moindre octet dans ce délai, une exception est levée.

​

distributed_cache_tcp_keep_alive_timeout_ms

N’a d’effet que dans ClickHouse Cloud. Durée, en millisecondes, pendant laquelle la connexion au serveur cache distribué doit rester inactive avant que TCP ne commence à envoyer des sondes de keepalive.

​

distributed_cache_throw_on_error

N’a d’effet que dans ClickHouse Cloud. Relance l’exception survenue lors de la communication avec le distributed cache ou l’exception renvoyée par le distributed cache. Sinon, revient à ignorer le distributed cache en cas d’erreur

​

distributed_cache_use_clients_cache_for_read

N’a d’effet que dans ClickHouse Cloud. Utilise le cache des clients pour les requêtes de lecture.

​

distributed_cache_use_clients_cache_for_write

N’a d’effet que dans ClickHouse Cloud. Utilise le cache des clients pour les requêtes d’écriture.

​

distributed_cache_wait_connection_from_pool_milliseconds

N’a d’effet que dans ClickHouse Cloud. Temps d’attente, en millisecondes, pour obtenir une connexion depuis le pool de connexions si distributed_cache_pool_behaviour_on_limit est défini sur wait

​

distributed_cache_write_request_max_tries

N’a d’effet que dans ClickHouse Cloud. Nombre de tentatives pour effectuer une requête d’écriture du distributed cache en cas d’échec

​

distributed_connections_pool_size

Le nombre maximal de connexions simultanées aux serveurs distants pour le traitement distribué de toutes les requêtes sur une même table Distributed. Nous recommandons de définir une valeur au moins égale au nombre de serveurs du cluster.

​

distributed_ddl_entry_format_version

Version de compatibilité des requêtes DDL distribuées (ON CLUSTER)

Valeur par défaut dans Cloud : 6.

​

distributed_ddl_output_mode

Définit le format du jeu de résultats d’une requête DDL distribuée.

Valeurs possibles :

• throw — Renvoie un jeu de résultats avec le statut d’exécution de la requête pour tous les hôtes où la requête est terminée. Si la requête a échoué sur certains hôtes, la première exception est relancée. Si la requête n’est pas encore terminée sur certains hôtes et que distributed_ddl_task_timeout est dépassé, l’exception TIMEOUT_EXCEEDED est levée.
• none — Similaire à throw, mais la requête DDL distribuée ne renvoie aucun jeu de résultats.
• null_status_on_timeout — Renvoie NULL comme statut d’exécution dans certaines lignes du jeu de résultats au lieu de lever TIMEOUT_EXCEEDED si la requête n’est pas terminée sur les hôtes correspondants.
• never_throw — Ne lève pas TIMEOUT_EXCEEDED et ne relance pas les exceptions si la requête a échoué sur certains hôtes.
• none_only_active - similaire à none, mais n’attend pas les répliques inactives de la base de données Replicated. Remarque : avec ce mode, il est impossible de savoir que la requête n’a pas été exécutée sur une réplique et qu’elle sera exécutée en arrière-plan.
• null_status_on_timeout_only_active — similaire à null_status_on_timeout, mais n’attend pas les répliques inactives de la base de données Replicated
• throw_only_active — similaire à throw, mais n’attend pas les répliques inactives de la base de données Replicated

Valeur par défaut dans Cloud : none_only_active.

​

distributed_ddl_task_timeout

Définit le délai d’attente des réponses aux requêtes DDL de tous les hôtes du cluster. Si une requête DDL n’a pas été exécutée sur tous les hôtes, la réponse contiendra une erreur de délai d’attente et la requête sera exécutée en mode asynchrone. Une valeur négative signifie un délai illimité.

Valeurs possibles :

• Entier positif.
• 0 — Mode asynchrone.
• Entier négatif — délai d’attente illimité.

​

distributed_foreground_insert

Alias : insert_distributed_sync

Active ou désactive l’insertion synchrone de données dans une table Distributed.

Par défaut, lors de l’insertion de données dans une table Distributed, le serveur ClickHouse envoie les données aux nœuds du cluster en arrière-plan. Lorsque distributed_foreground_insert=1, les données sont traitées de manière synchrone, et l’opération INSERT n’aboutit qu’après l’enregistrement de toutes les données sur tous les shards (au moins une réplique pour chaque shard si internal_replication vaut true).

Valeurs possibles :

• 0 — Les données sont insérées en arrière-plan.
• 1 — Les données sont insérées en mode synchrone.

Valeur par défaut dans Cloud : 1.

Voir aussi

• Moteur de table Distributed
• Gestion des tables distribuées

​

distributed_group_by_no_merge

Ne fusionne pas les états d’agrégation de différents serveurs lors du traitement distribué des requêtes ; vous pouvez l’utiliser lorsqu’il est certain que les clés sont différentes sur les différents shards

Valeurs possibles :

• 0 — Désactivé (le traitement final de la requête est effectué sur le nœud initiateur).
• 1 - Ne fusionne pas les états d’agrégation de différents serveurs lors du traitement distribué des requêtes (la requête est entièrement traitée sur le shard, l’initiateur se contente de relayer les données) ; peut être utilisé lorsqu’il est certain que les clés sont différentes sur les différents shards.
• 2 - Identique à 1, mais applique ORDER BY et LIMIT sur l’initiateur (ce qui n’est pas possible lorsque la requête est entièrement traitée sur le nœud distant, comme avec distributed_group_by_no_merge=1) ; peut être utilisé pour les requêtes avec ORDER BY et/ou LIMIT.

Exemple

SELECT *
FROM remote('127.0.0.{2,3}', system.one)
GROUP BY dummy
LIMIT 1
SETTINGS distributed_group_by_no_merge = 1
FORMAT PrettyCompactMonoBlock

┌─dummy─┐
│     0 │
│     0 │
└───────┘

SELECT *
FROM remote('127.0.0.{2,3}', system.one)
GROUP BY dummy
LIMIT 1
SETTINGS distributed_group_by_no_merge = 2
FORMAT PrettyCompactMonoBlock

┌─dummy─┐
│     0 │
└───────┘

​

distributed_index_analysis

L’analyse d’index distribuée sera répartie entre les répliques. Particulièrement utile avec un stockage partagé et de très grands volumes de données dans le cluster. S’appuie sur les répliques de cluster_for_parallel_replicas.

Voir aussi

• distributed_index_analysis_for_non_shared_merge_tree
• distributed_index_analysis_min_parts_to_activate
• distributed_index_analysis_min_indexes_bytes_to_activate

​

distributed_index_analysis_for_non_shared_merge_tree

Activer l’analyse d’index distribuée même pour les moteurs autres que SharedMergeTree (moteur disponible uniquement dans Cloud).

​

distributed_index_analysis_only_on_coordinator

Si ce paramètre est activé, l’analyse d’index distribuée s’effectue uniquement sur le coordinateur. Cela évite de générer des requêtes en O(N^2) lorsque le prédicat contient des sous-requêtes (par ex. IN (SELECT ...)), car sinon chaque réplique suiveuse déclencherait indépendamment sa propre analyse d’index distribuée, mais l’analyse d’index distribuée devient alors moins efficace si les sous-requêtes utilisent de grandes tables.

​

distributed_insert_skip_read_only_replicas

Permet d’ignorer les répliques en lecture seule pour les requêtes INSERT dans Distributed.

Valeurs possibles :

• 0 — INSERT se comporte comme d’habitude ; si l’opération cible une réplique en lecture seule, elle échoue
• 1 — L’initiateur ignorera les répliques en lecture seule avant d’envoyer les données aux shards.

​

distributed_plan_default_reader_bucket_count

Nombre par défaut de tâches pour la lecture parallèle dans une requête distribuée. Les tâches sont réparties entre les répliques.

​

distributed_plan_default_shuffle_join_bucket_count

Nombre de buckets par défaut du distributed shuffle-hash-join.

​

distributed_plan_execute_locally

Exécute localement toutes les tâches d’un plan de requête distribuée. Utile pour les tests et le débogage.

​

distributed_plan_force_exchange_kind

Force le type spécifié d’opérateurs Exchange entre les étapes d’une requête distribuée.

Valeurs possibles :

• ” - ne force aucun type d’opérateurs Exchange, laisse l’optimiseur choisir,
• ‘Persisted’ - utilise des fichiers temporaires dans le stockage d’objets,
• ‘Streaming’ - transmet les données d’échange sur le réseau.

​

distributed_plan_force_shuffle_aggregation

Utilise la stratégie d’agrégation Shuffle au lieu de PartialAggregation + Merge dans le plan de requête distribuée.

​

distributed_plan_max_rows_to_broadcast

Nombre maximal de lignes pour utiliser un broadcast join au lieu d’un shuffle join dans le plan de requête distribué.

​

distributed_plan_optimize_exchanges

Supprime les échanges inutiles dans le plan de requête distribuée. Désactivez ce paramètre pour le débogage.

​

distributed_plan_prefer_replicas_over_workers

Sérialise le plan de requête distribué pour l’exécuter sur les répliques.

​

distributed_product_mode

Modifie le comportement des sous-requêtes distribuées.

ClickHouse applique ce paramètre lorsque la requête contient le produit de tables distribuées, c’est-à-dire lorsqu’une requête sur une table distribuée contient une sous-requête non-GLOBAL sur une table distribuée.

Restrictions :

• S’applique uniquement aux sous-requêtes IN et JOIN.
• Uniquement si la section FROM utilise une table distribuée contenant plus d’un shard.
• Uniquement si la sous-requête porte sur une table distribuée contenant plus d’un shard.
• N’est pas utilisé pour une fonction de table remote.

Valeurs possibles :

• deny — Valeur par défaut. Interdit l’utilisation de ces types de sous-requêtes (renvoie l’exception “Double-distributed in/JOIN subqueries is denied”).
• local — Remplace la base de données et la table dans la sous-requête par leurs équivalents locaux pour le serveur de destination (shard), en conservant le IN/JOIN normal.
• global — Remplace la requête IN/JOIN par GLOBAL IN/GLOBAL JOIN.
• allow — Autorise l’utilisation de ces types de sous-requêtes.

​

distributed_push_down_limit

Active ou désactive l’application de LIMIT séparément sur chaque segment.

Cela permet d’éviter :

• l’envoi de lignes supplémentaires sur le réseau ;
• le traitement, sur l’initiateur, des lignes au-delà de la limite.

À partir de la version 21.9, il n’est plus possible d’obtenir de résultats inexacts, car distributed_push_down_limit ne modifie l’exécution de la requête que si au moins une des conditions suivantes est remplie :

• distributed_group_by_no_merge > 0.
• La requête n’a pas de GROUP BY/DISTINCT/LIMIT BY, mais comporte ORDER BY/LIMIT.
• La requête comporte GROUP BY/DISTINCT/LIMIT BY avec ORDER BY/LIMIT et :
  • optimize_skip_unused_shards est activé.
  • optimize_distributed_group_by_sharding_key est activé.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Voir aussi :

• distributed_group_by_no_merge
• optimize_skip_unused_shards
• optimize_distributed_group_by_sharding_key

​

distributed_replica_error_cap

• Type : entier non signé
• Valeur par défaut : 1000

Le nombre d’erreurs de chaque réplique est limité à cette valeur, afin d’éviter qu’une même réplique n’en accumule trop.

Voir aussi :

• load_balancing
• Moteur de table Distributed
• distributed_replica_error_half_life
• distributed_replica_max_ignored_errors

​

distributed_replica_error_half_life

• Type : secondes
• Valeur par défaut : 60 secondes

Contrôle la rapidité avec laquelle les erreurs des tables distribuées sont ramenées à zéro. Si une réplique est indisponible pendant un certain temps, accumule 5 erreurs et que distributed_replica_error_half_life est défini à 1 seconde, alors la réplique est de nouveau considérée comme normale 3 secondes après la dernière erreur.

Voir aussi :

• load_balancing
• Moteur de table Distributed
• distributed_replica_error_cap
• distributed_replica_max_ignored_errors

​

distributed_replica_max_ignored_errors

• Type : entier non signé
• Valeur par défaut : 0

Le nombre d’erreurs qui seront ignorées lors de la sélection des répliques (selon l’algorithme load_balancing).

Voir aussi :

• load_balancing
• Moteur de table Distributed
• distributed_replica_error_cap
• distributed_replica_error_half_life

​

do_not_merge_across_partitions_select_final

Améliore les requêtes FINAL en évitant les fusions entre partitions différentes.

Lorsqu’il est activé, lors des requêtes SELECT FINAL, les parts provenant de partitions différentes ne sont pas fusionnées entre elles. À la place, la fusion s’effectue uniquement au sein de chaque partition. Cela peut améliorer considérablement les performances des requêtes sur les tables partitionnées.

​

dynamic_disk_allow_from_env

Autorise l’utilisation des substitutions from_env dans la configuration dynamique des disques (c’est-à-dire dans les arguments de la fonction disk()). Désactivé par défaut afin d’empêcher les utilisateurs de lire des variables d’environnement arbitraires lors de la définition du stockage d’une table.

​

dynamic_disk_allow_from_zk

Autorise l’utilisation des substitutions from_zk dans la configuration dynamique des disques (c’est-à-dire dans les arguments de la fonction disk()). Désactivé par défaut.

​

dynamic_disk_allow_include

Autorise l’utilisation de include dans la configuration dynamique des disques (c’est-à-dire dans les arguments de la fonction disk()). Désactivé par défaut.

​

dynamic_throw_on_type_mismatch

Lorsqu’une fonction est appliquée à une colonne Dynamic à l’aide de l’implémentation par défaut, ce paramètre contrôle ce qui se passe pour les lignes dont le type réel est incompatible avec la fonction :

• true (par défaut) — lever une exception.
• false — renvoyer NULL pour ces lignes à la place.

​

empty_result_for_aggregation_by_constant_keys_on_empty_set

Renvoie un résultat vide en cas d’agrégation par clés constantes sur un ensemble vide.

​

empty_result_for_aggregation_by_empty_set

Renvoie un résultat vide lors d’une agrégation sans clés sur un ensemble vide.

​

enable_adaptive_memory_spill_scheduler

Permet au processeur de déverser de manière adaptative les données en mémoire vers le stockage externe. Seul grace join est actuellement pris en charge.

​

enable_add_distinct_to_in_subqueries

Active DISTINCT dans les sous-requêtes IN. Ce paramètre implique un compromis : son activation peut réduire considérablement la taille des tables temporaires transférées pour les sous-requêtes distribuées avec IN et accélérer significativement le transfert de données entre les shards, en garantissant que seules des valeurs uniques sont envoyées. Cependant, l’activation de ce paramètre ajoute un surcoût de fusion sur chaque nœud, car la déduplication (DISTINCT) doit être effectuée. Utilisez ce paramètre lorsque le transfert réseau constitue un goulot d’étranglement et que ce surcoût de fusion est acceptable.

​

enable_automatic_decision_for_merging_across_partitions_for_final

Si ce paramètre est activé, ClickHouse active automatiquement cette optimisation lorsque l’expression de la clé de partition est déterministe et que toutes les colonnes utilisées dans cette expression sont incluses dans la clé primaire. Cette déduction automatique garantit que les lignes ayant les mêmes valeurs de clé primaire appartiennent toujours à la même partition, ce qui permet d’éviter en toute sécurité les fusions entre partitions.

​

enable_blob_storage_log

Enregistrer des informations sur les opérations de stockage blob dans la table system.blob_storage_log

​

enable_blob_storage_log_for_read_operations

Enregistre des informations sur les opérations de lecture du stockage de blobs dans la table system.blob_storage_log. Nécessite également que enable_blob_storage_log soit activé.

​

enable_early_constant_folding

Active l’optimisation des requêtes consistant à analyser les résultats des fonctions et des sous-requêtes, puis à réécrire la requête si des constantes y sont présentes

​

enable_extended_results_for_datetime_functions

Active ou désactive le renvoi de résultats de type Date32 avec une plage étendue (par rapport au type Date) ou de type DateTime64 avec une plage étendue (par rapport au type DateTime).

Valeurs possibles :

• 0 — Les fonctions renvoient Date ou DateTime pour tous les types d’arguments.
• 1 — Les fonctions renvoient Date32 ou DateTime64 pour les arguments de type Date32 ou DateTime64, et Date ou DateTime dans les autres cas.

Le tableau ci-dessous présente le comportement de ce paramètre pour différentes fonctions de date et d’heure.

Function	enable_extended_results_for_datetime_functions = 0	enable_extended_results_for_datetime_functions = 1
toStartOfYear	Renvoie Date ou DateTime	Renvoie Date/DateTime pour une entrée de type Date/DateTime Renvoie Date32/DateTime64 pour une entrée de type Date32/DateTime64
toStartOfISOYear	Renvoie Date ou DateTime	Renvoie Date/DateTime pour une entrée de type Date/DateTime Renvoie Date32/DateTime64 pour une entrée de type Date32/DateTime64
toStartOfQuarter	Renvoie Date ou DateTime	Renvoie Date/DateTime pour une entrée de type Date/DateTime Renvoie Date32/DateTime64 pour une entrée de type Date32/DateTime64
toStartOfMonth	Renvoie Date ou DateTime	Renvoie Date/DateTime pour une entrée de type Date/DateTime Renvoie Date32/DateTime64 pour une entrée de type Date32/DateTime64
toStartOfWeek	Renvoie Date ou DateTime	Renvoie Date/DateTime pour une entrée de type Date/DateTime Renvoie Date32/DateTime64 pour une entrée de type Date32/DateTime64
toLastDayOfWeek	Renvoie Date ou DateTime	Renvoie Date/DateTime pour une entrée de type Date/DateTime Renvoie Date32/DateTime64 pour une entrée de type Date32/DateTime64
toLastDayOfMonth	Renvoie Date ou DateTime	Renvoie Date/DateTime pour une entrée de type Date/DateTime Renvoie Date32/DateTime64 pour une entrée de type Date32/DateTime64
toMonday	Renvoie Date ou DateTime	Renvoie Date/DateTime pour une entrée de type Date/DateTime Renvoie Date32/DateTime64 pour une entrée de type Date32/DateTime64
toStartOfDay	Renvoie DateTime Remarque : résultats incorrects pour les valeurs hors de l’intervalle 1970-2149	Renvoie DateTime pour une valeur d’entrée Date/DateTime Renvoie DateTime64 pour une valeur d’entrée Date32/DateTime64
toStartOfHour	Renvoie DateTime Remarque : résultats incorrects pour les valeurs en dehors de la plage 1970-2149	Renvoie DateTime pour une entrée Date/DateTime Renvoie DateTime64 pour une entrée Date32/DateTime64
toStartOfFifteenMinutes	Renvoie DateTime Remarque : résultats incorrects pour les valeurs hors de la plage 1970-2149	Renvoie DateTime pour les entrées Date/DateTime Renvoie DateTime64 pour les entrées Date32/DateTime64
toStartOfTenMinutes	Renvoie DateTime Remarque : résultats incorrects pour des valeurs hors de la plage 1970-2149	Renvoie DateTime pour une entrée de type Date/DateTime Renvoie DateTime64 pour une entrée de type Date32/DateTime64
toStartOfFiveMinutes	Renvoie DateTime Remarque : résultats incorrects pour les valeurs hors de la plage 1970-2149	Renvoie DateTime pour les entrées Date/DateTime Renvoie DateTime64 pour les entrées Date32/DateTime64
toStartOfMinute	Renvoie DateTime Remarque : résultats incorrects pour les valeurs hors de la plage 1970-2149	Renvoie DateTime pour les entrées Date/DateTime Renvoie DateTime64 pour les entrées Date32/DateTime64
timeSlot	Renvoie DateTime Remarque : résultats incorrects pour les valeurs hors de la plage 1970-2149	Renvoie DateTime pour les entrées Date/DateTime Renvoie DateTime64 pour les entrées Date32/DateTime64

​

enable_filesystem_cache

Utilise le cache pour le système de fichiers distant. Ce paramètre n’active ni ne désactive le cache des disques (cela doit être configuré via la config du disque), mais permet de contourner le cache pour certaines requêtes, si nécessaire

​

enable_filesystem_cache_log

Permet d’enregistrer le journal du cache du système de fichiers pour chaque requête

​

enable_filesystem_cache_on_write_operations

Active ou désactive le cache write-through. Si cette option est définie sur false, le cache write-through est désactivé pour les opérations d’écriture. Si elle est définie sur true, le cache write-through est activé tant que cache_on_write_operations est activé dans la section de configuration du disque de cache de la configuration du serveur. Consultez « Utilisation du cache local » pour plus de détails.

Valeur par défaut dans Cloud : 1.

​

enable_filesystem_read_prefetches_log

Consigne dans system.filesystem prefetch_log les opérations de prefetch pendant la requête. À utiliser uniquement pour les tests ou le débogage ; il n’est pas recommandé de l’activer par défaut.

​

enable_full_text_index

Alias : allow_experimental_full_text_index

Si ce paramètre est défini sur true, l’utilisation de l’index textuel est autorisée.

​

enable_global_with_statement

Propage les instructions WITH vers les requêtes UNION et toutes les sous-requêtes

​

enable_hdfs_pread

Active ou désactive pread pour les fichiers HDFS. Par défaut, hdfsPread est utilisé. Si cette option est désactivée, hdfsRead et hdfsSeek sont utilisés pour lire les fichiers HDFS.

​

enable_http_compression

Active ou désactive la compression des données dans la réponse à une requête HTTP.

Pour plus d’informations, consultez la description de l’interface HTTP.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

enable_identifier_resolve_cache

Active le cache de résolution des identifiants dans l’analyseur de requêtes. Le cache mutualise les nœuds d’alias résolus afin d’éviter une explosion de l’AST lorsque le même alias est utilisé plusieurs fois. Définissez la valeur sur false pour désactiver la mise en cache en cas de suspicion de résultats incorrects.

​

enable_job_stack_trace

Affiche la trace de pile du créateur d’un job lorsque celui-ci se solde par une exception. Désactivé par défaut pour éviter une surcharge de performances.

​

enable_join_fixed_hash_table_conversion

Activer la conversion de la table de hachage en tableau plat pour les jointures lorsque la clé est un seul entier avec une plage de valeurs réduite.

​

enable_join_runtime_filters

Filtre la partie gauche à l’aide de l’ensemble des clés de jointure JOIN collectées sur la partie droite à l’exécution.

​

enable_join_transitive_predicates

Infère des prédicats transitifs d’équi-jointure à partir des conditions de jointure existantes. Par exemple, étant donné A.x = B.x et B.x = C.x, un prédicat synthétique A.x = C.x est ajouté afin que l’optimiseur de l’ordre des jointures puisse prendre en compte des plans directs (A JOIN C).

​

enable_lazy_columns_replication

Active la réplication différée des colonnes dans JOIN et ARRAY JOIN, ce qui permet d’éviter de copier inutilement les mêmes lignes plusieurs fois en mémoire.

​

enable_lightweight_delete

Alias : allow_experimental_lightweight_delete

Active les mutations DELETE légères pour les tables MergeTree.

​

enable_lightweight_update

Aliases : allow_experimental_lightweight_update

Permet d’utiliser les mises à jour légères.

​

enable_materialized_cte

Active les expressions de table communes matérialisées ; elles sont prioritaires sur enable_global_with_statement

​

enable_memory_bound_merging_of_aggregation_results

Active la stratégie de fusion sous contrainte mémoire pour l’agrégation.

​

enable_multiple_prewhere_read_steps

Déplace davantage de conditions de WHERE vers PREWHERE, et effectue les lectures depuis le disque ainsi que le filtrage en plusieurs étapes s’il y a plusieurs conditions combinées avec AND

​

enable_named_columns_in_function_tuple

Générer des tuples nommés dans la fonction tuple() lorsque tous les noms sont uniques et peuvent être traités comme des identifiants non quotés.

​

enable_optimize_predicate_expression

Active le pushdown des prédicats dans les requêtes SELECT.

Le pushdown des prédicats peut réduire considérablement le trafic réseau des requêtes distribuées.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Utilisation

Examinez les requêtes suivantes :

1. SELECT count() FROM test_table WHERE date = '2018-10-10'
2. SELECT count() FROM (SELECT * FROM test_table) WHERE date = '2018-10-10'

Si enable_optimize_predicate_expression = 1, le temps d’exécution de ces requêtes est identique, car ClickHouse applique WHERE à la sous-requête pendant son traitement.

Si enable_optimize_predicate_expression = 0, le temps d’exécution de la deuxième requête est beaucoup plus long, car la clause WHERE n’est appliquée à l’ensemble des données qu’une fois la sous-requête terminée.

​

enable_optimize_predicate_expression_to_final_subquery

Permet de pousser le prédicat vers la sous-requête FINAL.

​

enable_order_by_all

Active ou désactive le tri à l’aide de la syntaxe ORDER BY ALL. Voir ORDER BY.

Valeurs possibles :

• 0 — Désactive ORDER BY ALL.
• 1 — Active ORDER BY ALL.

Exemple

Requête :

CREATE TABLE TAB(C1 Int, C2 Int, ALL Int) ENGINE=Memory();

INSERT INTO TAB VALUES (10, 20, 30), (20, 20, 10), (30, 10, 20);

SELECT * FROM TAB ORDER BY ALL; -- returns an error that ALL is ambiguous

SELECT * FROM TAB ORDER BY ALL SETTINGS enable_order_by_all = 0;

Résultat :

┌─C1─┬─C2─┬─ALL─┐
│ 20 │ 20 │  10 │
│ 30 │ 10 │  20 │
│ 10 │ 20 │  30 │
└────┴────┴─────┘

​

enable_parallel_blocks_marshalling

Affecte uniquement les requêtes distribuées. Si ce paramètre est activé, les blocs seront (dé)sérialisés et (dé)compressés dans les threads du pipeline (c.-à-d. avec un parallélisme supérieur à celui utilisé par défaut) avant/après leur envoi à l’initiateur.

​

enable_parsing_to_custom_serialization

Si la valeur est true, les données peuvent être interprétées directement dans des colonnes avec une sérialisation personnalisée (par ex. Sparse), selon les indications de sérialisation fournies par la table.

​

enable_positional_arguments

Active ou désactive la prise en charge des arguments positionnels pour les clauses GROUP BY, LIMIT BY et ORDER BY.

Valeurs possibles :

• 0 — Les arguments positionnels ne sont pas pris en charge.
• 1 — Les arguments positionnels sont pris en charge : les numéros de colonnes peuvent être utilisés à la place des noms de colonnes.

Exemple

Requête :

CREATE TABLE positional_arguments(one Int, two Int, three Int) ENGINE=Memory();

INSERT INTO positional_arguments VALUES (10, 20, 30), (20, 20, 10), (30, 10, 20);

SELECT * FROM positional_arguments ORDER BY 2,3;

Résultat :

┌─one─┬─two─┬─three─┐
│  30 │  10 │   20  │
│  20 │  20 │   10  │
│  10 │  20 │   30  │
└─────┴─────┴───────┘

​

enable_positional_arguments_for_projections

Active ou désactive la prise en charge des arguments positionnels dans les définitions de PROJECTION. Voir aussi le paramètre enable_positional_arguments.

Il s’agit d’un paramètre de niveau expert, et vous ne devriez pas le modifier si vous débutez avec ClickHouse.

Valeurs possibles :

• 0 — Les arguments positionnels ne sont pas pris en charge.
• 1 — Les arguments positionnels sont pris en charge : les numéros de colonnes peuvent être utilisés à la place des noms de colonnes.

​

enable_producing_buckets_out_of_order_in_aggregation

Autorise une agrégation économe en mémoire (voir distributed_aggregation_memory_efficient) à produire des buckets dans le désordre. Cela peut améliorer les performances lorsque la taille des buckets d’agrégation est déséquilibrée, en permettant à une réplique d’envoyer à l’initiateur des buckets avec des ID plus élevés pendant qu’elle traite encore certains buckets volumineux avec des ID plus faibles. L’inconvénient est une utilisation de la mémoire potentiellement plus élevée.

​

enable_reads_from_query_cache

Si cette option est activée, les résultats des requêtes SELECT sont extraits du cache de requêtes.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

enable_s3_requests_logging

Active la journalisation très détaillée des requêtes S3. À n’utiliser que pour le débogage.

​

enable_scalar_subquery_optimization

Si ce paramètre est défini sur true, il empêche les sous-requêtes scalaires de (dé)sérialiser de grandes valeurs scalaires et peut éventuellement éviter d’exécuter la même sous-requête plus d’une fois.

​

enable_scopes_for_with_statement

S’il est désactivé, les déclarations dans les clauses WITH parentes auront la même portée que si elles étaient déclarées dans la portée courante.

Notez qu’il s’agit d’un paramètre de compatibilité de l’analyseur, destiné à permettre l’exécution de certaines requêtes invalides que l’ancien analyseur pouvait exécuter.

​

enable_sharding_aggregator

Active l’optimisation de GROUP BY par partitionnement, qui répartit les lignes entre les threads en hachant la clé de regroupement, de sorte que chaque thread agrège un sous-ensemble distinct de clés sans phase de fusion.

Cette approche est efficace pour les clés à forte cardinalité avec des données uniformément réparties, mais peut être moins performante si la distribution des clés est très déséquilibrée ou si les requêtes comportent très peu de clés distinctes.

Valeurs possibles :

• 0 — L’optimisation d’agrégation par partitionnement est désactivée.
• 1 — L’optimisation d’agrégation par partitionnement est activée.

​

enable_shared_storage_snapshot_in_query

Si ce paramètre est activé, toutes les sous-requêtes d’une même requête partageront le même StorageSnapshot pour chaque table. Cela garantit une vue cohérente des données dans l’ensemble de la requête, même si la même table est utilisée plusieurs fois.

Ce paramètre est nécessaire pour les requêtes où la cohérence interne des data parts est importante. Exemple :

SELECT
    count()
FROM events
WHERE (_part, _part_offset) IN (
    SELECT _part, _part_offset
    FROM events
    WHERE user_id = 42
)

Sans ce paramètre, la requête externe et la requête interne peuvent s’exécuter sur des snapshots de données différents, ce qui peut entraîner des résultats incorrects.

L’activation de ce paramètre désactive l’optimisation qui supprime des snapshots les parties de données inutiles une fois l’étape de planification terminée. Par conséquent, les requêtes de longue durée peuvent conserver des parties obsolètes pendant toute leur exécution, ce qui retarde le nettoyage des parties et accroît la pression sur le stockage.

Ce paramètre s’applique actuellement uniquement aux tables de la famille MergeTree.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

enable_sharing_sets_for_mutations

Autorise le partage des objets set construits pour les sous-requêtes IN entre différentes tâches d’une même mutation. Cela réduit l’utilisation de la mémoire et la consommatio

​

enable_software_prefetch_in_aggregation

Activer l’utilisation du software prefetch dans l’agrégatio

​

enable_software_prefetch_in_join

Active l’utilisation du software prélecture dans la phase de probe du hash join afin de masquer la latence des accès mémoire pour les grandes tables de hachage.

​

enable_streaming_queries

Autorise les requêtes continues SELECT ... FROM t STREAM [CURSOR '{...}']. Lorsqu’il est désactivé, toute expression de table utilisant le modificateur STREAM est rejetée lors de la construction du plan. Ce paramètre constitue le contrôle principal de la fonctionnalité de requêtes en streaming ; des capacités supplémentaires peuvent être régies par leurs propres paramètres.

​

enable_time_time64_type

Alias : allow_experimental_time_time64_type

Permet de créer les types de données Time et Time64.

​

enable_unaligned_array_join

Autorise ARRAY JOIN avec plusieurs tableaux de tailles différentes. Lorsque ce paramètre est activé, les tableaux sont redimensionnés à la taille du plus grand.

​

enable_url_encoding

Permet d’activer ou de désactiver le décodage/l’encodage du chemin dans l’URI pour les tables du moteur URL.

Désactivé par défaut.

​

enable_vertical_final

Si ce paramètre est activé, les lignes dupliquées sont supprimées pendant FINAL en les marquant comme supprimées, puis en les filtrant ultérieurement au lieu de les fusionner

​

enable_writes_to_query_cache

Si cette option est activée, les résultats des requêtes SELECT sont stockés dans le cache de requêtes.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

enforce_strict_identifier_format

Si ce paramètre est activé, seuls les identifiants contenant des caractères alphanumériques et des underscores sont autorisés.

​

engine_file_allow_create_multiple_files

Active ou désactive la création d’un nouveau fichier à chaque insertion dans les tables utilisant le moteur File si le format comporte le suffixe (JSON, ORC, Parquet, etc.). Si ce paramètre est activé, un nouveau fichier est créé à chaque insertion selon le modèle de nommage suivant :

data.Parquet -> data.1.Parquet -> data.2.Parquet, etc.

Valeurs possibles :

• 0 — la requête INSERT ajoute les nouvelles données à la fin du fichier.
• 1 — la requête INSERT crée un nouveau fichier.

​

engine_file_empty_if_not_exists

Permet de sélectionner des données dans une table utilisant le moteur File, même sans fichier.

Valeurs possibles :

• 0 — SELECT lève une exception.
• 1 — SELECT renvoie un résultat vide.

​

engine_file_skip_empty_files

Active ou désactive la prise en compte des fichiers vides dans les tables du moteur File.

Valeurs possibles :

• 0 — SELECT lève une exception si le fichier vide n’est pas compatible avec le format demandé.
• 1 — SELECT renvoie un résultat vide pour un fichier vide.

​

engine_file_truncate_on_insert

Active ou désactive la troncature avant l’insertion dans les tables du moteur File.

Valeurs possibles :

• 0 — la requête INSERT ajoute de nouvelles données à la fin du fichier.
• 1 — la requête INSERT remplace le contenu existant du fichier par les nouvelles données.

​

engine_url_skip_empty_files

Active ou désactive la prise en compte des fichiers vides dans les tables du moteur URL.

Valeurs possibles :

• 0 — SELECT lève une exception si le fichier vide n’est pas compatible avec le format demandé.
• 1 — SELECT renvoie un résultat vide pour un fichier vide.

​

exact_rows_before_limit

Lorsqu’il est activé, ClickHouse fournit la valeur exacte de la statistique rows_before_limit_at_least, mais au prix d’une lecture complète des données avant la limite.

​

except_default_mode

Définit le mode par défaut de la requête EXCEPT. Valeurs possibles : chaîne vide, ‘ALL’, ‘DISTINCT’. Si elle est vide, une requête sans mode générera une exception.

​

exclude_materialize_skip_indexes_on_insert

Empêche la construction et le stockage des skip indexes spécifiés lors des INSERTs. Les skip indexes exclus seront tout de même construits et stockés lors des fusions ou par une requête explicite MATERIALIZE INDEX.

N’a aucun effet si materialize_skip_indexes_on_insert est défini sur false.

Exemple :

CREATE TABLE tab
(
    a UInt64,
    b UInt64,
    INDEX idx_a a TYPE minmax,
    INDEX idx_b b TYPE set(3)
)
ENGINE = MergeTree ORDER BY tuple();

SET exclude_materialize_skip_indexes_on_insert='idx_a'; -- idx_a will be not be updated upon insert
--SET exclude_materialize_skip_indexes_on_insert='idx_a, idx_b'; -- neither index would be updated on insert

INSERT INTO tab SELECT number, number / 50 FROM numbers(100); -- only idx_b is updated

-- since it is a session setting it can be set on a per-query level
INSERT INTO tab SELECT number, number / 50 FROM numbers(100, 100) SETTINGS exclude_materialize_skip_indexes_on_insert='idx_b';

ALTER TABLE tab MATERIALIZE INDEX idx_a; -- this query can be used to explicitly materialize the index

SET exclude_materialize_skip_indexes_on_insert = DEFAULT; -- reset setting to default

​

execute_exists_as_scalar_subquery

Exécute les sous-requêtes EXISTS non corrélées comme des sous-requêtes scalaires. Comme pour les sous-requêtes scalaires, le cache est utilisé et le pliage de constantes s’applique au résultat.

Valeur par défaut dans Cloud : 0.

​

external_storage_connect_timeout_sec

Délai d’expiration de la connexion, en secondes. Actuellement pris en charge uniquement pour MySQL

​

external_storage_max_read_bytes

Limite le nombre maximal d’octets lorsque la table avec un moteur externe doit écrire les données d’historique. Actuellement, ce paramètre n’est pris en charge que pour le moteur de table MySQL, le moteur de base de données et le dictionnaire. S’il est égal à 0, ce paramètre est désactivé

​

external_storage_max_read_rows

Limite le nombre maximal de lignes lorsqu’une table utilisant un moteur externe doit purger les données d’historique. Actuellement, ce paramètre n’est pris en charge que pour le moteur de table MySQL, le moteur de base de données et le dictionnaire. Si cette valeur est égale à 0, ce paramètre est désactivé

​

external_storage_rw_timeout_sec

Délai d’expiration en lecture/écriture, en secondes. Actuellement pris en charge uniquement pour MySQL

​

external_table_functions_use_nulls

Définit comment les fonctions de table mysql, postgresql et odbc utilisent des colonnes Nullable.

Valeurs possibles :

• 0 — La fonction de table utilise explicitement des colonnes Nullable.
• 1 — La fonction de table utilise implicitement des colonnes Nullable.

Utilisation

Si ce paramètre est défini sur 0, la fonction de table ne rend pas les colonnes Nullable et insère à la place des valeurs par défaut au lieu de NULL. Cela s’applique également aux valeurs NULL dans les tableaux.

​

external_table_strict_query

Si cette option est définie sur true, il est interdit de transformer une expression en filtre local pour les requêtes sur des tables externes.

​

extract_key_value_pairs_max_pairs_per_row

Alias : extract_kvp_max_pairs_per_row

Nombre maximal de paires que la fonction extractKeyValuePairs peut produire. Sert de garde-fou pour éviter une consommation excessive de mémoire.

​

extremes

Indique s’il faut comptabiliser les valeurs extrêmes (les valeurs minimales et maximales dans les colonnes du résultat de la requête). Accepte 0 ou 1. Par défaut : 0 (désactivé). Pour plus d’informations, consultez la section « Valeurs extrêmes ».

​

fallback_to_stale_replicas_for_distributed_queries

Force l’exécution d’une requête sur une réplique obsolète si les données à jour ne sont pas disponibles. Voir Réplication.

ClickHouse sélectionne la réplique la plus pertinente parmi les répliques obsolètes de la table.

Utilisé lors de l’exécution d’un SELECT sur une table distribuée pointant vers des tables répliquées.

Par défaut, 1 (activé).

​

file_like_engine_default_partition_strategy

Stratégie de partition par défaut pour les moteurs de type fichier.

​

filesystem_cache_allow_background_download

Autorise le cache du système de fichiers à placer en file d’attente des téléchargements en arrière-plan pour les données lues depuis un stockage distant. Désactivez cette option pour que les téléchargements restent au premier plan pour la requête/session en cours.

​

filesystem_cache_boundary_alignment

Alignement aux limites du cache du système de fichiers. Ce paramètre s’applique uniquement aux lectures ne provenant pas du disque (par exemple, pour le cache des moteurs de table distants / fonctions de table, mais pas pour la configuration de stockage des tables MergeTree). La valeur 0 signifie qu’aucun alignement n’est appliqué.

​

filesystem_cache_enable_background_download_during_fetch

N’a d’effet que dans ClickHouse Cloud. Temps d’attente pour obtenir le verrou du cache lors de la réservation d’espace dans le cache du système de fichiers

​

filesystem_cache_enable_background_download_for_metadata_files_in_packed_storage

N’a d’effet que dans ClickHouse Cloud. Temps d’attente pour obtenir le verrou du cache lors de la réservation d’espace dans le cache du système de fichiers

​

filesystem_cache_max_download_size

Taille maximale du cache du système de fichiers distant qu’une seule requête peut télécharger

​

filesystem_cache_name

Nom du cache du système de fichiers à utiliser avec les moteurs de table sans état ou les lacs de données

​

filesystem_cache_prefer_bigger_buffer_size

Privilégie une taille de tampon plus importante si le cache du système de fichiers est activé, afin d’éviter l’écriture de petits segments de fichier, qui dégradent les performances du cache. En revanche, l’activation de ce paramètre peut augmenter l’utilisation de la mémoire.

​

filesystem_cache_reserve_space_wait_lock_timeout_milliseconds

Temps d’attente pour obtenir le verrou du cache lors de la réservation d’espace dans le cache du système de fichiers

​

filesystem_cache_segments_batch_size

Limite de la taille d’un lot de segments de fichier qu’un tampon de lecture peut demander au cache. Une valeur trop faible entraînera un nombre excessif de requêtes vers le cache, tandis qu’une valeur trop élevée peut ralentir l’éviction du cache

​

filesystem_cache_skip_download_if_exceeds_per_query_cache_write_limit

Alias : skip_download_if_exceeds_query_cache

Ne pas télécharger depuis le système de fichiers distant si la taille dépasse celle du cache de requêtes

​

filesystem_prefetch_max_memory_usage

Utilisation mémoire maximale pour les prélectures.

Valeur par défaut dans Cloud : 10 % de la mémoire totale.

​

filesystem_prefetch_step_bytes

Pas de prélecture, en octets. Zéro signifie auto : le pas de prélecture optimal sera déduit automatiquement de façon approximative, mais il ne sera pas forcément optimal à 100 %. La valeur réelle peut être différente en raison du paramètre filesystem_prefetch_min_bytes_for_single_read_task

​

filesystem_prefetch_step_marks

Étape de prélecture en marks. Zéro signifie auto : l’étape de prélecture approximativement la plus adaptée sera déduite automatiquement, mais elle ne sera pas forcément optimale à 100 %. La valeur réelle peut être différente en raison du paramètre filesystem_prefetch_min_bytes_for_single_read_task

​

filesystem_prefetches_limit

Nombre maximal de prélectures. Zéro signifie sans limite. Il est recommandé d’utiliser le paramètre filesystem_prefetches_max_memory_usage si vous souhaitez limiter le nombre de prélectures

​

final

Applique automatiquement le modificateur FINAL à toutes les tables d’une requête auxquelles FINAL s’applique, y compris les tables jointes, les tables des sous-requêtes et les tables distribuées.

Valeurs possibles :

• 0 - désactivé
• 1 - activé

Exemple :

CREATE TABLE test
(
    key Int64,
    some String
)
ENGINE = ReplacingMergeTree
ORDER BY key;

INSERT INTO test FORMAT Values (1, 'first');
INSERT INTO test FORMAT Values (1, 'second');

SELECT * FROM test;
┌─key─┬─some───┐
│   1 │ second │
└─────┴────────┘
┌─key─┬─some──┐
│   1 │ first │
└─────┴───────┘

SELECT * FROM test SETTINGS final = 1;
┌─key─┬─some───┐
│   1 │ second │
└─────┴────────┘

SET final = 1;
SELECT * FROM test;
┌─key─┬─some───┐
│   1 │ second │
└─────┴────────┘

​

finalize_projection_parts_synchronously

Lorsqu’il est activé, les parties de projection sont finalisées de manière synchrone pendant l’INSERT, ce qui réduit l’utilisation maximale de la mémoire au prix d’un parallélisme moindre des téléversements S3. Par défaut, le flux de sortie de chaque projection reste actif jusqu’à la finalisation de la part entière (y compris toutes les projections), ce qui permet de faire se chevaucher les téléversements S3, mais augmente l’utilisation maximale de la mémoire proportionnellement au nombre de projections. Ce paramètre n’affecte que le chemin d’INSERT ; les opérations de merge et de mutation finalisent déjà les projections de manière synchrone.

​

flatten_nested

Définit le format des données des colonnes Nested.

Valeurs possibles :

• 1 — La colonne Nested est convertie en tableaux distincts.
• 0 — La colonne Nested reste un tableau unique de tuples.

Utilisation

Si le paramètre est défini sur 0, il est possible d’utiliser un niveau d’imbrication arbitraire.

Exemples

Requête :

SET flatten_nested = 1;
CREATE TABLE t_nest (`n` Nested(a UInt32, b UInt32)) ENGINE = MergeTree ORDER BY tuple();

SHOW CREATE TABLE t_nest;

Résultat :

┌─statement───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.t_nest
(
    `n.a` Array(UInt32),
    `n.b` Array(UInt32)
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS index_granularity = 8192 │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Requête :

SET flatten_nested = 0;

CREATE TABLE t_nest (`n` Nested(a UInt32, b UInt32)) ENGINE = MergeTree ORDER BY tuple();

SHOW CREATE TABLE t_nest;

Résultat :

┌─statement──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.t_nest
(
    `n` Nested(a UInt32, b UInt32)
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS index_granularity = 8192 │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

​

force_aggregate_partitions_independently

Force l’utilisation de l’optimisation lorsqu’elle est applicable, même si les heuristiques ont décidé de ne pas l’utiliser

​

force_aggregation_in_order

Ce paramètre est utilisé par le serveur lui-même pour prendre en charge les requêtes distribuées. Ne le modifiez pas manuellement, car cela perturberait le fonctionnement normal. (Force l’utilisation de l’agrégation dans l’ordre sur les nœuds distants lors d’une agrégation distribuée).

​

force_data_skipping_indices

Désactive l’exécution de la requête si les index de saut de données spécifiés n’ont pas été utilisés.

Considérez l’exemple suivant :

CREATE TABLE data
(
    key Int,
    d1 Int,
    d1_null Nullable(Int),
    INDEX d1_idx d1 TYPE minmax GRANULARITY 1,
    INDEX d1_null_idx assumeNotNull(d1_null) TYPE minmax GRANULARITY 1
)
Engine=MergeTree()
ORDER BY key;

SELECT * FROM data_01515;
SELECT * FROM data_01515 SETTINGS force_data_skipping_indices=''; -- query will produce CANNOT_PARSE_TEXT error.
SELECT * FROM data_01515 SETTINGS force_data_skipping_indices='d1_idx'; -- query will produce INDEX_NOT_USED error.
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='d1_idx'; -- Ok.
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='`d1_idx`'; -- Ok (example of full featured parser).
SELECT * FROM data_01515 WHERE d1 = 0 SETTINGS force_data_skipping_indices='`d1_idx`, d1_null_idx'; -- query will produce INDEX_NOT_USED error, since d1_null_idx is not used.
SELECT * FROM data_01515 WHERE d1 = 0 AND assumeNotNull(d1_null) = 0 SETTINGS force_data_skipping_indices='`d1_idx`, d1_null_idx'; -- Ok.

​

force_grouping_standard_compatibility

Fait en sorte que la fonction GROUPING renvoie 1 lorsque l’argument n’est pas utilisé comme clé d’agrégation

​

force_index_by_date

Désactive l’exécution de la requête si l’index ne peut pas être utilisé sur la date.

Fonctionne avec les tables de la famille MergeTree.

Si force_index_by_date=1, ClickHouse vérifie si la requête contient une condition sur la clé de date qui peut être utilisée pour restreindre les plages de données. S’il n’existe pas de condition appropriée, une exception est levée. Cependant, le système ne vérifie pas si cette condition réduit la quantité de données à lire. Par exemple, la condition Date != ' 2000-01-01 ' est acceptable même lorsqu’elle correspond à toutes les données de la table (c’est-à-dire que l’exécution de la requête nécessite un parcours complet). Pour plus d’informations sur les plages de données dans les tables MergeTree, consultez MergeTree.

​

force_optimize_projection

Active ou désactive l’utilisation obligatoire des projections dans les requêtes SELECT lorsque l’optimisation des projections est activée (voir le paramètre optimize_use_projections).

Valeurs possibles :

• 0 — L’optimisation des projections n’est pas obligatoire.
• 1 — L’optimisation des projections est obligatoire.

​

force_optimize_projection_name

S’il est défini sur une chaîne non vide, le système vérifie que cette projection est utilisée au moins une fois dans la requête.

Valeurs possibles :

• chaîne : nom de la projection utilisée dans une requête

​

force_optimize_skip_unused_shards

Active ou désactive l’exécution des requêtes lorsque optimize_skip_unused_shards est activé et qu’il n’est pas possible d’ignorer les shards inutilisés. Si cela n’est pas possible et que ce paramètre est activé, une exception est levée.

Valeurs possibles :

• 0 — Désactivé. ClickHouse ne lève pas d’exception.
• 1 — Activé. L’exécution des requêtes est désactivée uniquement si la table possède une clé de sharding.
• 2 — Activé. L’exécution des requêtes est désactivée, qu’une clé de sharding soit définie ou non pour la table.

​

force_optimize_skip_unused_shards_nesting

Contrôle le comportement de force_optimize_skip_unused_shards en fonction du niveau d’imbrication de la requête distribuée (lorsqu’une table Distributed interroge une autre table Distributed). Ce paramètre requiert donc toujours force_optimize_skip_unused_shards.

Valeurs possibles :

• 0 - Désactivé, force_optimize_skip_unused_shards s’applique toujours.
• 1 — Active force_optimize_skip_unused_shards uniquement pour le premier niveau.
• 2 — Active force_optimize_skip_unused_shards jusqu’au deuxième niveau.

​

force_primary_key

Désactive l’exécution de la requête si l’indexation par la clé primaire n’est pas possible.

Fonctionne avec les tables de la famille MergeTree.

Si force_primary_key=1, ClickHouse vérifie si la requête comporte une condition sur la clé primaire pouvant être utilisée pour restreindre les plages de données. S’il n’existe pas de condition appropriée, il lève une exception. Cependant, il ne vérifie pas si cette condition réduit la quantité de données à lire. Pour plus d’informations sur les plages de données dans les tables MergeTree, consultez MergeTree.

​

force_remove_data_recursively_on_drop

Supprime récursivement les données lors d’une requête DROP. Évite l’erreur « Directory not empty », mais peut supprimer silencieusement des données detached

​

formatdatetime_e_with_space_padding

Le spécificateur de format ‘%e’ dans la fonction ‘formatDateTime’ affiche les jours à un seul chiffre précédés d’une espace, par ex. ’ 2’ au lieu de ‘2’.

​

formatdatetime_f_prints_scale_number_of_digits

Le spécificateur de format ‘%f’ de la fonction ‘formatDateTime’ n’affiche que le nombre de chiffres correspondant à la précision d’un DateTime64, au lieu d’en afficher systématiquement 6.

​

formatdatetime_f_prints_single_zero

Le spécificateur de format ‘%f’ dans la fonction ‘formatDateTime’ affiche un seul zéro au lieu de six zéros lorsque la valeur formatée ne comporte pas de secondes fractionnaires.

​

formatdatetime_format_without_leading_zeros

Les spécificateurs de format ‘%c’, ‘%l’ et ‘%k’ de la fonction ‘formatDateTime’ affichent les mois et les heures sans zéro initial.

​

formatdatetime_parsedatetime_m_is_month_name

Le spécificateur de format ‘%M’ dans les fonctions ‘formatDateTime’ et ‘parseDateTime’ affiche/analyse le nom du mois au lieu des minutes.

​

fsync_metadata

Active ou désactive fsync lors de l’écriture des fichiers .sql. Activé par défaut.

Il peut être pertinent de le désactiver si le serveur possède des millions de petites tables qui sont constamment créées et supprimées.

​

function_base58_max_input_size

Taille maximale, en octets, d’une valeur d’entrée unique pour les fonctions base58Encode, base58Decode et tryBase58Decode. La conversion générique base58 est quadratique par rapport à la longueur de l’entrée ; une seule valeur volumineuse peut donc mettre très longtemps à s’exécuter. base58 est conçu pour des données courtes (clés, hachages, adresses) ; la valeur par défaut de 10 Ko constitue donc un seuil de sécurité généreux. base58Encode et base58Decode lèvent TOO_LARGE_STRING_SIZE pour les entrées plus volumineuses, tandis que tryBase58Decode renvoie une chaîne vide. Une valeur de 0 désactive la limite (c’était le comportement avant l’introduction de ce paramètre). Les fonctions linéaires base32 et base64 ne sont pas affectées.

​

function_date_trunc_return_type_behavior

Permet de modifier le comportement du type de retour de la fonction dateTrunc.

Valeurs possibles :

• 0 - Lorsque le deuxième argument est DateTime64/Date32, le type de retour sera DateTime64/Date32 quelle que soit l’unité de temps du premier argument.
• 1 - Pour Date32, le résultat est toujours Date. Pour DateTime64, le résultat est DateTime pour les unités de temps second et supérieures.

​

function_implementation

Choisissez l’implémentation de la fonction pour une cible spécifique ou une variante (expérimental). Si vide, active toutes les implémentations.

​

function_json_value_return_type_allow_complex

Indique s’il est permis de renvoyer un type complexe (tel que : struct, array, map) pour la fonction json_value.

SELECT JSON_VALUE('{"hello":{"world":"!"}}', '$.hello') settings function_json_value_return_type_allow_complex=true

┌─JSON_VALUE('{"hello":{"world":"!"}}', '$.hello')─┐
│ {"world":"!"}                                    │
└──────────────────────────────────────────────────┘

1 row in set. Elapsed: 0.001 sec.

Valeurs possibles :

• true — Autorise.
• false — Interdit.

​

function_json_value_return_type_allow_nullable

Détermine s’il est autorisé de renvoyer NULL lorsque la valeur n’existe pas pour la fonction JSON_VALUE.

SELECT JSON_VALUE('{"hello":"world"}', '$.b') settings function_json_value_return_type_allow_nullable=true;

┌─JSON_VALUE('{"hello":"world"}', '$.b')─┐
│ ᴺᵁᴸᴸ                                   │
└────────────────────────────────────────┘

1 row in set. Elapsed: 0.001 sec.

Valeurs possibles :

• true — Autorisé.
• false — Interdit.

​

function_locate_has_mysql_compatible_argument_order

Contrôle l’ordre des arguments de la fonction locate.

Valeurs possibles :

• 0 — La fonction locate accepte les arguments (haystack, needle[, start_pos]).
• 1 — La fonction locate accepte les arguments (needle, haystack, [, start_pos]) (comportement compatible avec MySQL)

​

function_range_max_elements_in_block

Définit le seuil de sécurité du volume de données généré par la fonction range. Il définit le nombre maximal de valeurs générées par la fonction par bloc de données (somme des tailles des tableaux pour chaque ligne d’un bloc).

Valeurs possibles :

• Entier positif.

Voir aussi

• max_block_size
• min_insert_block_size_rows

​

function_sleep_max_microseconds_per_block

Nombre maximal de microsecondes pendant lesquelles la fonction sleep est autorisée à se mettre en veille pour chaque bloc. Si un utilisateur l’appelle avec une valeur plus élevée, elle lève une exception. Il s’agit d’un seuil de sécurité.

​

function_visible_width_behavior

Version du comportement de visibleWidth. 0 - compte uniquement le nombre de points de code ; 1 - compte correctement les caractères de largeur nulle et les caractères combinés, compte les caractères à pleine largeur comme deux, estime la largeur des tabulations et compte les caractères de suppression.

​

functions_h3_default_if_invalid

Si false, les fonctions h3, par exemple h3CellAreaM2, lèvent une exception si l’entrée est invalide. Si true, elles renvoient 0 ou la valeur par défaut.

​

geo_distance_returns_float64_on_float64_arguments

Si les quatre arguments des fonctions geoDistance, greatCircleDistance et greatCircleAngle sont de type Float64, elles retournent un Float64 et utilisent la double précision pour les calculs internes. Dans les versions précédentes de ClickHouse, ces fonctions retournaient toujours un Float32.

​

geotoh3_argument_order

La fonction ‘geoToH3’ accepte (lon, lat) si ce paramètre est défini sur ‘lon_lat’, et (lat, lon) s’il est défini sur ‘lat_lon’.

​

glob_expansion_max_elements

Nombre maximal d’adresses autorisées (pour les stockages externes, les fonctions de table, etc.).

​

grace_hash_join_initial_buckets

Nombre initial de buckets pour le grace hash join

​

grace_hash_join_max_buckets

Nombre maximal de buckets pour le grace hash join

​

group_by_overflow_mode

Définit ce qui se produit lorsque le nombre de clés uniques pour l’agrégation dépasse la limite :

• throw : lever une exception
• break : arrêter l’exécution de la requête et renvoyer un résultat partiel
• any : poursuivre l’agrégation pour les clés déjà présentes dans le set, sans ajouter de nouvelles clés au set.

L’utilisation de la valeur ‘any’ permet d’exécuter une approximation de GROUP BY. La qualité de cette approximation dépend de la nature statistique des données.

​

group_by_two_level_threshold

Nombre de clés à partir duquel une agrégation à deux niveaux démarre. 0 - le seuil n’est pas défini.

​

group_by_two_level_threshold_bytes

Taille, en octets, de l’état d’agrégation à partir de laquelle une agrégation à deux niveaux commence à être utilisée. 0 : le seuil n’est pas défini. L’agrégation à deux niveaux est utilisée lorsqu’au moins l’un des seuils est déclenché.

​

group_by_use_nulls

Modifie la manière dont la clause GROUP BY traite les types des clés d’agrégation. Lorsque les spécificateurs ROLLUP, CUBE ou GROUPING SETS sont utilisés, certaines clés d’agrégation peuvent ne pas être utilisées pour produire certaines lignes de résultat. Les colonnes correspondant à ces clés sont remplies soit avec la valeur par défaut, soit avec NULL dans les lignes correspondantes, selon ce paramètre.

Valeurs possibles :

• 0 — La valeur par défaut du type de clé d’agrégation est utilisée pour produire les valeurs manquantes.
• 1 — ClickHouse exécute GROUP BY de la même manière que le prescrit la norme SQL. Les types des clés d’agrégation sont convertis en Nullable. Les colonnes correspondant aux clés d’agrégation sont remplies avec NULL pour les lignes où elles n’ont pas été utilisées.

Voir aussi :

• clause GROUP BY

​

h3togeo_lon_lat_result_order

La fonction ‘h3ToGeo’ renvoie (lon, lat) si true, et (lat, lon) sinon.

​

handshake_timeout_ms

Délai d’expiration, en millisecondes, pour la réception du paquet Hello provenant des répliques lors de la négociation initiale.

​

hdfs_create_new_file_on_insert

Active ou désactive la création d’un nouveau fichier à chaque insertion dans les tables du moteur HDFS. Si cette option est activée, un nouveau fichier HDFS est créé à chaque insertion, avec un nom de ce type :

initial : data.Parquet.gz -> data.1.Parquet.gz -> data.2.Parquet.gz, etc.

Valeurs possibles :

• 0 — la requête INSERT ajoute de nouvelles données à la fin du fichier.
• 1 — la requête INSERT crée un nouveau fichier.

​

hdfs_ignore_file_doesnt_exist

Ignorer l’absence d’un fichier lorsqu’il n’existe pas pendant la lecture de certaines clés.

Valeurs possibles :

• 1 — SELECT renvoie un résultat vide.
• 0 — SELECT lève une exception.

​

hdfs_replication

Le nombre réel de réplications peut être indiqué lors de la création du fichier HDFS.

​

hdfs_skip_empty_files

Permet d’ignorer ou non les fichiers vides dans les tables du moteur HDFS.

Valeurs possibles :

• 0 — SELECT lève une exception si un fichier vide n’est pas compatible avec le format demandé.
• 1 — SELECT renvoie un résultat vide pour un fichier vide.

​

hdfs_throw_on_zero_files_match

Génère une erreur si aucun fichier ne correspond aux règles d’expansion des motifs glob.

Valeurs possibles :

• 1 — SELECT lève une exception.
• 0 — SELECT renvoie un résultat vide.

​

hdfs_truncate_on_insert

Active ou désactive le tronquage avant une insertion dans les tables du moteur HDFS. Si cette option est désactivée, une exception sera levée en cas de tentative d’insertion si un fichier existe déjà dans HDFS.

Valeurs possibles :

• 0 — la requête INSERT ajoute de nouvelles données à la fin du fichier.
• 1 — la requête INSERT remplace le contenu existant du fichier par les nouvelles données.

​

hedged_connection_timeout_ms

Délai d’expiration pour établir une connexion avec une réplique pour les requêtes Hedged

​

highlight_max_matches_per_row

Définit le nombre maximal de correspondances mises en surbrillance par ligne dans la fonction highlight. Utilisez-le pour éviter une utilisation excessive de la mémoire lors de la mise en surbrillance de motifs très répétitifs dans de grands textes.

Valeurs possibles :

• Entier positif.

​

hnsw_candidate_list_size_for_search

Taille de la liste dynamique de candidats lors de la recherche dans l’index de similarité vectorielle, également appelée « ef_search ».

​

hsts_max_age

Durée d’expiration du HSTS. 0 signifie que le HSTS est désactivé.

​

http_connection_timeout

Délai d’expiration de la connexion HTTP (en secondes).

Valeurs possibles :

• Tout nombre entier positif.
• 0 - Désactivé (délai d’expiration infini).

​

http_headers_progress_interval_ms

N’envoyez pas les en-têtes HTTP X-ClickHouse-Progress plus souvent qu’à l’intervalle spécifié.

​

http_headers_read_timeout

Temps maximal, en secondes, pour lire tous les en-têtes de requête HTTP. Il s’agit d’un délai global pour toute la phase d’analyse des en-têtes, et non d’un délai d’expiration par lecture. Protège contre les attaques de type slowloris, dans lesquelles un client envoie lentement les données d’en-tête afin de maintenir les connexions ouvertes.

​

http_make_head_request

Le paramètre http_make_head_request permet d’effectuer une requête HEAD lors de la lecture de données via HTTP afin d’obtenir des informations sur le fichier à lire, comme sa taille. Étant activé par défaut, il peut être utile de désactiver ce paramètre lorsque le serveur ne prend pas en charge les requêtes HEAD.

​

http_max_field_name_size

Longueur maximale d’un nom de champ dans les en-têtes de requête HTTP, les paramètres de requête et les données de formulaire.

​

http_max_field_value_size

Longueur maximale de la valeur d’un champ dans les en-têtes de requête HTTP, les paramètres de requête et les données de formulaire.

​

http_max_fields

Nombre maximal de champs dans les en-têtes de requête HTTP, les paramètres de requête et les données de formulaire.

​

http_max_multipart_form_data_size

Limite de taille du contenu multipart/form-data. Ce paramètre ne peut pas être défini via des paramètres d’URL et doit être configuré dans un profil utilisateur. Notez que le contenu est analysé et que les tables externes sont créées en mémoire avant le début de l’exécution de la requête. C’est la seule limite qui s’applique à cette étape (les limites de memory usage et de temps d’exécution maximal n’ont aucun effet lors de la lecture des form data HTTP).

​

http_max_request_header_size

Taille totale maximale, en octets, de tous les en-têtes de requête HTTP (noms et valeurs combinés).

​

http_max_request_param_data_size

Limite de la taille des données de requête utilisées comme paramètre de requête dans les requêtes HTTP prédéfinies.

​

http_max_tries

Nombre maximal de tentatives de lecture via HTTP.

​

http_max_uri_size

Définit la longueur maximale de l’URI d’une requête HTTP.

Valeurs possibles :

• Entier positif.

​

http_native_compression_disable_checksumming_on_decompress

Active ou désactive la vérification de la somme de contrôle lors de la décompression des données POST HTTP envoyées par le client. Utilisé uniquement avec le format de compression natif de ClickHouse (non utilisé avec gzip ou deflate).

Pour plus d’informations, consultez la description de l’interface HTTP.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

http_receive_timeout

Délai d’attente de réception HTTP (en secondes).

Valeurs possibles :

• N’importe quel entier positif.
• 0 - Désactivé (délai d’attente infini).

​

http_response_buffer_size

Le nombre d’octets à mettre en tampon dans la mémoire du serveur avant d’envoyer une réponse HTTP au client ou d’écrire sur disque (lorsque http_wait_end_of_query est activé).

​

http_response_headers

Permet d’ajouter ou de remplacer les en-têtes HTTP que le serveur renverra dans la réponse lorsqu’une requête aboutit. Cela n’affecte que l’interface HTTP.

Si l’en-tête est déjà défini par défaut, la valeur fournie le remplacera. Si l’en-tête n’est pas défini par défaut, il sera ajouté à la liste des en-têtes. Les en-têtes définis par défaut par le serveur et non remplacés par ce paramètre seront conservés.

Ce paramètre permet de définir un en-tête avec une valeur constante. Il n’existe actuellement aucun moyen de définir un en-tête avec une valeur calculée dynamiquement.

Ni les noms ni les valeurs ne peuvent contenir de caractères de contrôle ASCII.

Si vous implémentez une application UI qui permet aux utilisateurs de modifier les paramètres tout en prenant des décisions en fonction des en-têtes renvoyés, il est recommandé de restreindre ce paramètre à readonly.

Exemple : SET http_response_headers = '{"Content-Type": "image/png"}'

​

http_retry_initial_backoff_ms

Délai minimal de backoff, en millisecondes, lors d’une nouvelle tentative de lecture via HTTP

​

http_retry_max_backoff_ms

Nombre maximal de millisecondes de backoff lors d’une nouvelle tentative de lecture via HTTP

​

http_send_timeout

Délai d’expiration de l’envoi HTTP (en secondes).

Valeurs possibles :

• Tout nombre entier positif.
• 0 - Désactivé (délai d’expiration infini).

Cela s’applique uniquement au profil par défaut. Un redémarrage du serveur est nécessaire pour que les modifications prennent effet.

​

http_skip_not_found_url_for_globs

Ignorer les URL correspondant à des globs en cas d’erreur HTTP_NOT_FOUND

​

http_wait_end_of_query

Active la mise en tampon de la réponse HTTP côté serveur.

​

http_write_exception_in_output_format

Écrit l’exception dans le format de sortie afin de produire une sortie valide. Fonctionne avec les formats JSON et XML.

​

http_zlib_compression_level

Définit le niveau de compression des données dans la réponse à une requête HTTP si enable_http_compression = 1.

Valeurs possibles : de 1 à 9.

​

iceberg_compaction_data_cleanup

Le délai après lequel les données seront supprimées.

​

iceberg_compaction_delay_bias

Temps d’attente minimal entre deux opérations de compaction en arrière-plan.

​

iceberg_data_file_size_lower_threshold_compaction

Seuil inférieur de taille des fichiers de données pour la compaction dans Iceberg.

​

iceberg_data_file_size_upper_threshold_compaction

Seuil supérieur de taille des fichiers de données pour la compaction dans Iceberg.

​

iceberg_delete_data_on_drop

Indique s’il faut supprimer tous les fichiers Iceberg lors de la suppression ou non.

​

iceberg_expire_default_max_ref_age_ms

Valeur par défaut de la propriété de table Iceberg history.expire.max-ref-age-ms, utilisée par expire_snapshots lorsque cette propriété n’est pas définie.

​

iceberg_expire_default_max_snapshot_age_ms

Valeur par défaut de la propriété de table Iceberg history.expire.max-snapshot-age-ms utilisée par expire_snapshots en l’absence de cette propriété.

​

iceberg_expire_default_min_snapshots_to_keep

Valeur par défaut de la propriété de table Iceberg history.expire.min-snapshots-to-keep qu’expire_snapshots utilise lorsque cette propriété est absente.

​

iceberg_insert_max_bytes_in_data_file

Taille maximale, en octets, du fichier de données Parquet Iceberg lors d’une opération d’insertion.

​

iceberg_insert_max_partitions

Nombre maximal de partitions autorisées pour une opération d’insertion dans le moteur de table Iceberg.

​

iceberg_insert_max_rows_in_data_file

Nombre maximal de lignes dans un fichier de données Parquet Iceberg lors d’une opération d’insertion.

​

iceberg_max_number_datafiles_to_compact

Seuil pour la compaction des fichiers de données dans Iceberg.

​

iceberg_metadata_compression_method

Méthode de compression du fichier .metadata.json.

​

iceberg_metadata_log_level

Contrôle le niveau de journalisation des métadonnées des tables Iceberg dans system.iceberg_metadata_log. Ce paramètre peut généralement être modifié à des fins de débogage.

Valeurs possibles :

• none - Aucun journal de métadonnées.
• metadata - Fichier racine metadata.json.
• manifest_list_metadata - Tout ce qui précède + métadonnées de la liste de manifestes avro correspondant à un snapshot.
• manifest_list_entry - Tout ce qui précède + entrées de la liste de manifestes avro.
• manifest_file_metadata - Tout ce qui précède + métadonnées des fichiers manifestes avro parcourus.
• manifest_file_entry - Tout ce qui précède + entrées des fichiers manifestes avro parcourus.

​

iceberg_metadata_staleness_ms

S’il est différent de zéro, la récupération des métadonnées Iceberg depuis le catalogue distant est ignorée s’il existe un snapshot de métadonnées mis en cache plus récent que la fenêtre d’ancienneté indiquée. Zéro signifie qu’il faut toujours récupérer la version la plus récente des métadonnées depuis le catalogue distant. Définir ce paramètre sur une valeur non nulle revient à accepter un certain décalage des métadonnées en échange d’une latence plus faible pour les opérations de lecture.

​

iceberg_orphan_files_older_than_seconds

Seuil d’ancienneté par défaut, en secondes, pour la suppression des fichiers orphelins dans les tables Iceberg. Les fichiers plus récents que ce seuil ne sont pas considérés comme orphelins. Utilisé lorsque l’argument older_than est omis de l’appel à la procédure remove_orphan_files(). La valeur par défaut est 259200 (3 jours).

​

iceberg_snapshot_id

Interrogez la table Iceberg à l’aide de l’ID de snapshot spécifié.

​

iceberg_timestamp_ms

Interrogez une table Iceberg à l’aide du snapshot en vigueur pour un horodatage donné.

​

idle_connection_timeout

Délai avant la fermeture des connexions TCP inactives après le nombre de secondes spécifié.

Valeurs possibles :

• Entier positif (0 : fermeture immédiate, après 0 seconde).

​

ignore_cold_parts_seconds

N’a d’effet que dans ClickHouse Cloud. Exclut les nouvelles parties de données des requêtes SELECT tant qu’elles n’ont pas été préchauffées (voir cache_populated_by_fetch) ou qu’elles n’ont pas atteint cet âge en secondes. Uniquement pour Replicated-/SharedMergeTree.

​

ignore_data_skipping_indices

Ignore les index de saut de données spécifiés s’ils sont utilisés par la requête.

Considérez l’exemple suivant :

CREATE TABLE data
(
    key Int,
    x Int,
    y Int,
    INDEX x_idx x TYPE minmax GRANULARITY 1,
    INDEX y_idx y TYPE minmax GRANULARITY 1,
    INDEX xy_idx (x,y) TYPE minmax GRANULARITY 1
)
Engine=MergeTree()
ORDER BY key;

INSERT INTO data VALUES (1, 2, 3);

SELECT * FROM data;
SELECT * FROM data SETTINGS ignore_data_skipping_indices=''; -- query will produce CANNOT_PARSE_TEXT error.
SELECT * FROM data SETTINGS ignore_data_skipping_indices='x_idx'; -- Ok.
SELECT * FROM data SETTINGS ignore_data_skipping_indices='na_idx'; -- Ok.

SELECT * FROM data WHERE x = 1 AND y = 1 SETTINGS ignore_data_skipping_indices='xy_idx',force_data_skipping_indices='xy_idx' ; -- query will produce INDEX_NOT_USED error, since xy_idx is explicitly ignored.
SELECT * FROM data WHERE x = 1 AND y = 2 SETTINGS ignore_data_skipping_indices='xy_idx';

La requête sans ignorer aucun index :

EXPLAIN indexes = 1 SELECT * FROM data WHERE x = 1 AND y = 2;

Expression ((Projection + Before ORDER BY))
  Filter (WHERE)
    ReadFromMergeTree (default.data)
    Indexes:
      PrimaryKey
        Condition: true
        Parts: 1/1
        Granules: 1/1
      Skip
        Name: x_idx
        Description: minmax GRANULARITY 1
        Parts: 0/1
        Granules: 0/1
      Skip
        Name: y_idx
        Description: minmax GRANULARITY 1
        Parts: 0/0
        Granules: 0/0
      Skip
        Name: xy_idx
        Description: minmax GRANULARITY 1
        Parts: 0/0
        Granules: 0/0

En ignorant l’index xy_idx :

EXPLAIN indexes = 1 SELECT * FROM data WHERE x = 1 AND y = 2 SETTINGS ignore_data_skipping_indices='xy_idx';

Expression ((Projection + Before ORDER BY))
  Filter (WHERE)
    ReadFromMergeTree (default.data)
    Indexes:
      PrimaryKey
        Condition: true
        Parts: 1/1
        Granules: 1/1
      Skip
        Name: x_idx
        Description: minmax GRANULARITY 1
        Parts: 0/1
        Granules: 0/1
      Skip
        Name: y_idx
        Description: minmax GRANULARITY 1
        Parts: 0/0
        Granules: 0/0

Compatible avec les tables de la famille MergeTree.

​

ignore_drop_queries_probability

Si cette option est activée, le serveur ignorera toutes les requêtes DROP table avec la probabilité spécifiée (pour les moteurs Memory et JOIN, il remplacera DROP par TRUNCATE). Cette option est utilisée à des fins de test

​

ignore_format_null_for_explain

Si cette option est activée, FORMAT Null est ignoré pour les requêtes EXPLAIN, et le format de sortie par défaut est utilisé à la place. Si elle est désactivée, les requêtes EXPLAIN avec FORMAT Null ne produisent aucune sortie (comportement rétrocompatible).

​

ignore_materialized_views_with_dropped_target_table

Ignorer les vues matérialisées dont la table cible a été supprimée lors de l’envoi vers les vues

​

ignore_on_cluster_for_replicated_access_entities_queries

Ignore la clause ON CLUSTER pour les requêtes de gestion des entités d’accès répliquées.

​

ignore_on_cluster_for_replicated_database

Ignore toujours la clause ON CLUSTER pour les requêtes DDL avec des bases de données répliquées.

​

ignore_on_cluster_for_replicated_named_collections_queries

Ignorer la clause ON CLUSTER pour les requêtes d’administration des collections nommées répliquées.

​

ignore_on_cluster_for_replicated_udf_queries

Ignore la clause ON CLUSTER pour les requêtes de gestion des UDF répliquées.

​

implicit_select

Permet d’écrire des requêtes SELECT simples sans le mot-clé SELECT au début, ce qui facilite une utilisation de type calculatrice ; par ex., 1 + 2 devient une requête valide.

Dans clickhouse-local, il est activé par défaut et peut être désactivé explicitement.

​

implicit_table_at_top_level

S’il n’est pas vide, les requêtes sans FROM au niveau supérieur liront à partir de cette table au lieu de system.one.

Ce paramètre est utilisé dans clickhouse-local pour le traitement des données d’entrée. Le paramètre peut être défini explicitement par un utilisateur, mais il n’est pas destiné à ce type d’utilisation.

Les sous-requêtes ne sont pas affectées par ce paramètre (ni les sous-requêtes scalaires, FROM ou IN). Les SELECT au niveau supérieur des chaînes UNION, INTERSECT, EXCEPT sont traités uniformément et sont affectés par ce paramètre, quel que soit leur regroupement entre parenthèses. La manière dont ce paramètre affecte les vues et les requêtes distribuées n’est pas spécifiée.

Le paramètre accepte un nom de table (la table est alors résolue à partir de la base de données courante) ou un nom qualifié de la forme ‘database.table’. Les noms de base de données et de table ne doivent pas être entre guillemets : seuls les identifiants simples sont autorisés.

​

implicit_transaction

Si cette option est activée et qu’aucune transaction n’est déjà en cours, la requête est encapsulée dans une transaction complète (begin + commit ou rollback)

​

inject_random_order_for_select_without_order_by

Si ce paramètre est activé, ‘ORDER BY rand()’ est injecté dans les requêtes SELECT sans clause ORDER BY. S’applique uniquement à une profondeur de sous-requête = 0. Les sous-requêtes et INSERT INTO … SELECT ne sont pas affectés. Si la construction de plus haut niveau est UNION, ‘ORDER BY rand()’ est injecté indépendamment dans chacune de ses branches. Utile uniquement pour les tests et le développement (l’absence de ORDER BY est une source de résultats de requête non déterministes).

​

insert_allow_materialized_columns

Si ce paramètre est activé, les colonnes matérialisées sont autorisées dans INSERT.

​

insert_deduplicate

Active ou désactive la déduplication des blocs de INSERT (pour les tables Replicated*).

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Par défaut, les blocs insérés dans des tables répliquées par l’instruction INSERT sont dédupliqués (voir Réplication des données). Pour les tables répliquées, seuls les 100 blocs les plus récents de chaque partition sont dédupliqués par défaut (voir replicated_deduplication_window, replicated_deduplication_window_seconds). Pour les tables non répliquées, voir non_replicated_deduplication_window.

​

insert_deduplication_token

Ce paramètre permet à l’utilisateur de définir son propre mécanisme de déduplication dans MergeTree/ReplicatedMergeTree. Par exemple, en fournissant une valeur unique pour ce paramètre dans chaque instruction INSERT, l’utilisateur peut éviter que les mêmes données insérées soient dédupliquées.

Valeurs possibles :

• Toute chaîne de caractères

insert_deduplication_token n’est utilisé pour la déduplication que lorsqu’il n’est pas vide.

Pour les tables répliquées, par défaut, seules les 100 insertions les plus récentes de chaque partition sont dédupliquées (voir replicated_deduplication_window, replicated_deduplication_window_seconds). Pour les tables non répliquées, voir non_replicated_deduplication_window.

insert_deduplication_token fonctionne au niveau de la partition (comme la somme de contrôle insert_deduplication). Plusieurs partitions peuvent avoir le même insert_deduplication_token.

Exemple :

CREATE TABLE test_table
( A Int64 )
ENGINE = MergeTree
ORDER BY A
SETTINGS non_replicated_deduplication_window = 100;

INSERT INTO test_table SETTINGS insert_deduplication_token = 'test' VALUES (1);

-- the next insert won't be deduplicated because insert_deduplication_token is different
INSERT INTO test_table SETTINGS insert_deduplication_token = 'test1' VALUES (1);

-- the next insert will be deduplicated because insert_deduplication_token
-- is the same as one of the previous
INSERT INTO test_table SETTINGS insert_deduplication_token = 'test' VALUES (2);

SELECT * FROM test_table

┌─A─┐
│ 1 │
└───┘
┌─A─┐
│ 1 │
└───┘

​

insert_keeper_fault_injection_probability

Probabilité approximative de défaillance d’une requête Keeper lors d’un insert. La valeur valide se situe dans l’intervalle [0.0f, 1.0f]

​

insert_keeper_fault_injection_seed

0 : graine aléatoire ; sinon, valeur du paramètre

​

insert_keeper_max_retries

Ce paramètre définit le nombre maximal de nouvelles tentatives pour les requêtes ClickHouse Keeper (ou ZooKeeper) lors de l’insertion dans un MergeTree répliqué. Seules les requêtes Keeper ayant échoué à cause d’une erreur réseau, d’un timeout de session Keeper ou d’un timeout de requête peuvent faire l’objet de nouvelles tentatives.

Valeurs possibles :

• Entier positif.
• 0 — Les nouvelles tentatives sont désactivées

Valeur par défaut Cloud : 20.

Les nouvelles tentatives pour les requêtes Keeper sont effectuées après un certain délai d’attente. Ce délai est contrôlé par les paramètres suivants : insert_keeper_retry_initial_backoff_ms, insert_keeper_retry_max_backoff_ms. La première nouvelle tentative est effectuée après le délai insert_keeper_retry_initial_backoff_ms. Les délais suivants sont calculés comme suit :

timeout = min(insert_keeper_retry_max_backoff_ms, latest_timeout * 2)

Par exemple, si insert_keeper_retry_initial_backoff_ms=100, insert_keeper_retry_max_backoff_ms=10000 et insert_keeper_max_retries=8, les délais seront de 100, 200, 400, 800, 1600, 3200, 6400, 10000.

Au-delà de la tolérance aux pannes, les nouvelles tentatives visent à offrir une meilleure expérience utilisateur : elles permettent d’éviter de renvoyer une erreur lors de l’exécution d’INSERT si Keeper redémarre, par exemple à la suite d’une mise à niveau.

​

insert_keeper_retry_initial_backoff_ms

Délai initial (en millisecondes) avant de réessayer une requête Keeper ayant échoué lors de l’exécution d’une requête INSERT

Valeurs possibles :

• Entier positif.
• 0 — Aucun délai d’attente

​

insert_keeper_retry_max_backoff_ms

Délai maximal (en millisecondes) avant de retenter une requête Keeper ayant échoué pendant l’exécution de la requête INSERT

Valeurs possibles :

• Entier positif.
• 0 — Le délai maximal n’est pas limité

​

insert_null_as_default

Active ou désactive l’insertion des valeurs par défaut à la place de NULL dans les colonnes dont le type de données n’est pas Nullable. Si le type de la colonne n’est pas Nullable et que ce paramètre est désactivé, l’insertion de NULL provoque une exception. Si le type de la colonne est Nullable, les valeurs NULL sont insérées telles quelles, quel que soit ce paramètre.

Ce paramètre s’applique aux requêtes INSERT … SELECT. Notez que les sous-requêtes SELECT peuvent être concaténées avec la clause UNION ALL.

Valeurs possibles :

• 0 — L’insertion de NULL dans une colonne non Nullable provoque une exception.
• 1 — La valeur par défaut de la colonne est insérée à la place de NULL.

​

insert_quorum

Ce paramètre ne s’applique pas à SharedMergeTree, voir la cohérence de SharedMergeTree pour plus d’informations.

Active les écritures avec quorum.

• Si insert_quorum < 2, les écritures avec quorum sont désactivées.
• Si insert_quorum >= 2, les écritures avec quorum sont activées.
• Si insert_quorum = 'auto', utilise la majorité (number_of_replicas / 2 + 1) comme nombre de quorum.

Écritures avec quorum

INSERT réussit uniquement lorsque ClickHouse parvient à écrire correctement les données sur insert_quorum répliques pendant insert_quorum_timeout. Si, pour une raison quelconque, le nombre de répliques sur lesquelles l’écriture a réussi n’atteint pas insert_quorum, l’écriture est considérée comme ayant échoué et ClickHouse supprimera le bloc inséré de toutes les répliques où les données ont déjà été écrites.

Lorsque insert_quorum_parallel est désactivé, toutes les répliques du quorum sont cohérentes, c’est-à-dire qu’elles contiennent les données de toutes les requêtes INSERT précédentes (la séquence INSERT est linéarisée). Lors de la lecture de données écrites à l’aide de insert_quorum et lorsque insert_quorum_parallel est désactivé, vous pouvez activer la cohérence séquentielle pour les requêtes SELECT à l’aide de select_sequential_consistency.

ClickHouse génère une exception :

• Si le nombre de répliques disponibles au moment de la requête est inférieur à insert_quorum.
• Lorsque insert_quorum_parallel est désactivé et qu’une tentative d’écriture de données est effectuée alors que le bloc précédent n’a pas encore été inséré sur insert_quorum répliques. Cette situation peut se produire si l’utilisateur essaie d’exécuter une autre requête INSERT sur la même table avant que la précédente avec insert_quorum ne soit terminée.

Voir aussi :

• insert_quorum_timeout
• insert_quorum_parallel
• select_sequential_consistency

​

insert_quorum_parallel

Ce paramètre ne s’applique pas à SharedMergeTree. Pour plus d’informations, voir cohérence de SharedMergeTree.

Active ou désactive le parallélisme pour les requêtes INSERT avec quorum. S’il est activé, des requêtes INSERT supplémentaires peuvent être envoyées avant la fin des requêtes précédentes. S’il est désactivé, les écritures supplémentaires dans la même table seront rejetées.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Voir aussi :

• insert_quorum
• insert_quorum_timeout
• select_sequential_consistency

​

insert_quorum_timeout

Délai d’écriture avec quorum, en millisecondes. Si ce délai est dépassé et qu’aucune écriture n’a encore eu lieu, ClickHouse génère une exception et le client doit répéter la query pour écrire le même block sur la même replica ou sur une autre replica.

Voir aussi :

• insert_quorum
• insert_quorum_parallel
• select_sequential_consistency

​

insert_shard_id

S’il est différent de 0, spécifie le shard de la table Distributed dans lequel les données seront insérées de façon synchrone.

Si la valeur de insert_shard_id est incorrecte, le serveur lèvera une exception.

Pour obtenir le nombre de shards dans requested_cluster, vous pouvez consulter la configuration du serveur ou utiliser cette requête :

SELECT uniq(shard_num) FROM system.clusters WHERE cluster = 'requested_cluster';

Valeurs possibles :

• 0 — Désactivé.
• Un nombre quelconque de 1 à shards_num de la table Distributed correspondante.

Exemple

Requête :

CREATE TABLE x AS system.numbers ENGINE = MergeTree ORDER BY number;
CREATE TABLE x_dist AS x ENGINE = Distributed('test_cluster_two_shards_localhost', currentDatabase(), x);
INSERT INTO x_dist SELECT * FROM numbers(5) SETTINGS insert_shard_id = 1;
SELECT * FROM x_dist ORDER BY number ASC;

Résultat :

┌─number─┐
│      0 │
│      0 │
│      1 │
│      1 │
│      2 │
│      2 │
│      3 │
│      3 │
│      4 │
│      4 │
└────────┘

​

interactive_delay

Intervalle, en microsecondes, auquel le système vérifie si l’exécution de la requête a été annulée et envoie la progression.

​

intersect_default_mode

Définit le mode par défaut dans la requête INTERSECT. Valeurs possibles : chaîne vide, ‘ALL’, ‘DISTINCT’. Si elle est vide, une requête sans mode lèvera une exception.

​

jemalloc_collect_profile_samples_in_trace_log

Collecter les échantillons d’allocation et de désallocation de jemalloc dans le journal de trace.

​

jemalloc_enable_profiler

Active le profileur jemalloc pour la requête. Jemalloc échantillonne les allocations ainsi que toutes les désallocations des allocations échantillonnées. Les profils peuvent être vidés à l’aide de SYSTEM JEMALLOC FLUSH PROFILE, qui peut servir à l’analyse des allocations. Les échantillons peuvent également être stockés dans system.trace_log à l’aide de la config jemalloc_collect_global_profile_samples_in_trace_log ou du paramètre de requête jemalloc_collect_profile_samples_in_trace_log. Voir le profilage des allocations

​

jemalloc_profile_text_collapsed_use_count

Lors de l’utilisation du format de sortie « collapsed » pour le heap profile jemalloc, agrège par nombre d’allocations plutôt que par octets. Lorsque false (par défaut), chaque pile est pondérée par le nombre d’octets actuellement alloués ; lorsque true, par le nombre d’allocations actives.

​

jemalloc_profile_text_output_format

Format de sortie du heap profile jemalloc dans la table system.jemalloc_profile_text. Peut être : ‘raw’ (profil brut), ‘symbolized’ (format jeprof avec symboles) ou ‘collapsed’ (format FlameGraph).

​

jemalloc_profile_text_symbolize_with_inline

Indique s’il faut inclure les frames inline lors de la symbolisation du heap profile jemalloc. Lorsqu’il est activé, les frames inline sont incluses, ce qui peut ralentir considérablement le processus de symbolisation ; lorsqu’il est désactivé, elles sont ignorées. N’affecte que les formats de sortie ‘symbolized’ et ‘collapsed’.

​

join_algorithm

Spécifie l’algorithme de JOIN utilisé.

Plusieurs algorithmes peuvent être spécifiés, et un algorithme disponible sera choisi pour une requête donnée en fonction du type, de la strictness et du moteur de table.

Valeurs possibles :

• grace_hash

Le grace hash join est utilisé. Grace hash offre une option d’algorithme permettant d’exécuter des jointures complexes de façon performante tout en limitant l’utilisation de la mémoire.

La première phase d’un grace join lit la table de droite et la répartit dans N buckets selon la valeur de hachage des colonnes clés (initialement, N vaut grace_hash_join_initial_buckets). Cela est fait de manière à 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 mémoire (par exemple, telle que définie par max_bytes_in_join, le nombre de buckets est augmenté, ainsi que le bucket assigné à chaque ligne. Toutes les lignes qui n’appartiennent pas au bucket actuel sont vidées sur disque et réaffectées.

Prend en charge INNER/LEFT/RIGHT/FULL ALL/ANY JOIN.

• hash

L’algorithme de hash join est utilisé. C’est l’implémentation la plus générique : elle 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 hash join qui répartit les données dans des buckets et construit plusieurs tables de hachage au lieu d’une seule, de manière concurrente, 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.

Les 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 dans ClickHouse diffère légèrement de l’implémentation classique. D’abord, ClickHouse trie la table de droite par clés de jointure en 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é nested loop) 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 moteurs de stockage spéciaux tels que Dictionary, EmbeddedRocksDB et les tables MergeTree.

Pour les tables MergeTree, l’algorithme pousse les filtres sur les clés de jointure directement 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 des parcours complets de la table de droite pour chaque bloc de la table de gauche.

Prend en charge les jointures INNER et LEFT, et uniquement les clés de jointure d’égalité sur une seule colonne, sans autres conditions.

• auto

Lorsqu’il est défini sur auto, hash join est d’abord essayé, puis l’algorithme bascule à la volée vers un autre algorithme si la limite mémoire est dépassée.

• full_sorting_merge

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

• prefer_partial_merge

ClickHouse essaie toujours d’utiliser partial_merge join 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.-à-d. essayer d’utiliser direct join puis hash join (dans cet ordre).

​

join_any_take_last_row

Modifie le comportement des opérations de jointure avec la strictness ANY.

Ce paramètre s’applique uniquement aux opérations JOIN avec des tables utilisant le moteur Join.

Valeurs possibles :

• 0 — Si la table de droite comporte plus d’une ligne correspondante, seule la première trouvée est utilisée pour la jointure.
• 1 — Si la table de droite comporte 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

​

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 normal en 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 n’a 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.

​

join_on_disk_max_files_to_merge

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 RAM utilisée augmente et moins les E/S disque sont nécessaires.

Valeurs possibles :

• Tout entier positif à partir de 2.

​

join_output_by_rowlist_perkey_rows_threshold

Seuil inférieur du nombre moyen de lignes par clé dans la table de droite permettant de déterminer s’il faut générer la sortie sous forme de liste de lignes dans un hash join.

​

join_overflow_mode

Définit l’action que ClickHouse effectue lorsqu’une jointure atteint l’une des limites suivantes :

• max_bytes_in_join
• max_rows_in_join

Ce paramètre n’est pris en compte que pour les valeurs hash et parallel_hash de join_algorithm. Les autres algorithmes (par exemple, partial_merge, grace_hash, auto) gèrent ces limites différemment — en déversant 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

​

join_runtime_bloom_filter_bytes

Taille, en octets, du filtre de Bloom utilisé comme filtre d’exécution pour JOIN (voir le paramètre enable_join_runtime_filters).

​

join_runtime_bloom_filter_hash_functions

Nombre de fonctions de hachage dans un filtre de Bloom utilisé comme filtre d’exécution de JOIN (voir le paramètre enable_join_runtime_filters).

​

join_runtime_bloom_filter_max_ratio_of_set_bits

Si la proportion de bits à 1 dans un filtre de Bloom d’exécution dépasse ce ratio, le filtre est entièrement désactivé afin de réduire la surcharge.

​

join_runtime_filter_blocks_to_skip_before_reenabling

Nombre de blocs ignorés avant de tenter de réactiver dynamiquement un filtre d’exécution précédemment désactivé en raison d’un taux de filtrage insuffisant.

​

join_runtime_filter_exact_values_limit

Nombre maximal d’éléments du filtre d’exécution stockés tels quels dans un ensemble ; au-delà de ce seuil, il passe à un filtre de Bloom.

​

join_runtime_filter_from_fixed_hash_table

Lorsque le côté build du hash join est converti en FixedHashMap (voir enable_join_fixed_hash_table_conversion), cette table de hachage est utilisée directement comme filtre d’exécution.

​

join_runtime_filter_pass_ratio_threshold_for_disabling

Si le ratio entre le nombre de lignes retenues et le nombre de lignes vérifiées dépasse ce seuil, le filtre d’exécution est considéré comme peu performant et est désactivé pour les join_runtime_filter_blocks_to_skip_before_reenabling blocs suivants afin de réduire la surcharge.

​

join_to_sort_maximum_table_rows

Le nombre maximal de lignes de la table de droite permettant de déterminer s’il faut réordonner la table de droite par clé dans un LEFT JOIN ou un INNER JOIN.

​

join_to_sort_minimum_perkey_rows

Le seuil minimal du nombre moyen de lignes par clé dans la table de droite pour déterminer s’il faut réordonner la table de droite par clé dans un LEFT JOIN ou un INNER JOIN. Ce paramètre garantit que l’optimisation n’est pas appliquée aux clés de table peu denses

​

join_use_nulls

Définit le comportement de JOIN. Lors de la fusion 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 SQL standard. Le type du champ correspondant est converti en Nullable, et les cellules vides sont remplies avec NULL.

​

joined_block_split_single_row

Permet de découper le résultat du hash join en groupes de lignes correspondant chacune à une seule ligne de la table de gauche. Cela peut réduire la consommation mémoire lorsqu’une ligne a de nombreuses correspondances dans la table de droite, mais peut augmenter l’utilisation du CPU. Notez que max_joined_block_size_rows != 0 est obligatoire pour que ce paramètre prenne effet. Combiné à ce paramètre, max_joined_block_size_bytes est utile pour éviter une consommation mémoire excessive en cas de données déséquilibrées, lorsque certaines lignes volumineuses ont de nombreuses correspondances dans la table de droite.

​

joined_subquery_requires_alias

Exige que les sous-requêtes jointes et les fonctions de table aient des alias afin de garantir une qualification correcte des noms.

​

kafka_disable_num_consumers_limit

Désactive la limite de kafka_num_consumers, qui dépend du nombre de cœurs CPU disponibles.

​

kafka_max_wait_ms

Le temps d’attente, en millisecondes, avant nouvelle tentative de lecture des messages depuis Kafka.

Valeurs possibles :

• Entier positif.
• 0 — Délai d’attente infini.

Voir aussi :

• Apache Kafka

​

keeper_map_strict_mode

Active des vérifications supplémentaires lors des opérations sur KeeperMap. Par exemple, déclenche une exception lors d’une insertion pour une clé déjà existante

​

keeper_max_retries

Nombre maximal de tentatives pour les opérations générales de Keeper

​

keeper_retry_initial_backoff_ms

Délai initial de backoff pour les opérations générales de Keeper

​

keeper_retry_max_backoff_ms

Délai maximal de backoff pour les opérations générales de Keeper

​

least_greatest_legacy_null_behavior

Si ce paramètre est activé, les fonctions ‘least’ et ‘greatest’ renvoient NULL si l’un de leurs arguments est NULL.

​

legacy_column_name_of_tuple_literal

Utilise tous les noms des éléments des grands littéraux de tuple comme noms de colonne au lieu d’un hash. Ce paramètre existe uniquement pour des raisons de compatibilité. Il est pertinent de le définir sur ‘true’ lors d’une mise à jour progressive du cluster depuis une version antérieure à 21.7 vers une version supérieure.

​

lightweight_delete_mode

Mode de la requête interne de mise à jour exécutée dans le cadre d’une suppression légère.

Valeurs possibles :

• alter_update - exécute la requête ALTER UPDATE, qui crée une mutation lourde.
• lightweight_update - exécute une mise à jour légère si possible, sinon exécute ALTER UPDATE.
• lightweight_update_force - exécute une mise à jour légère si possible, sinon lève une exception.

​

lightweight_deletes_sync

Identique à mutations_sync, mais contrôle uniquement l’exécution des suppressions légères.

Valeurs possibles :

Valeur	Description
0	Les mutations s’exécutent de manière asynchrone.
1	La requête attend que les suppressions légères soient terminées sur le serveur actuel.
2	La requête attend que les suppressions légères soient terminées sur toutes les répliques (si elles existent).
3	La requête attend uniquement les répliques actives. Pris en charge uniquement pour SharedMergeTree. Pour ReplicatedMergeTree, le comportement est le même que mutations_sync = 2.

Voir aussi

• Synchronisation des requêtes ALTER
• Mutations

Valeur par défaut dans Cloud : 1.

​

limit

Définit le nombre maximal de lignes à renvoyer dans le résultat de la requête. Cette valeur ajuste celle définie par la clause LIMIT, de sorte que la limite spécifiée dans la requête ne puisse pas dépasser celle définie par ce paramètre.

Valeurs possibles :

• 0 — Le nombre de lignes n’est pas limité.
• Entier positif.

​

load_balancing

Spécifie l’algorithme de sélection des répliques utilisé pour le traitement des requêtes distribuées.

ClickHouse prend en charge les algorithmes suivants pour sélectionner les répliques :

• Random (par défaut)
• Nearest hostname
• Hostname levenshtein distance
• Hostname longest common prefix
• Hostname longest common suffix
• In order
• First or random
• Round robin

Voir aussi :

• distributed_replica_max_ignored_errors

​

Random (par défaut)

load_balancing = random

Le nombre d’erreurs est comptabilisé pour chaque réplique. La requête est envoyée à la réplique qui a le moins d’erreurs et, s’il y en a plusieurs, à n’importe laquelle d’entre elles. Inconvénients : la proximité du serveur n’est pas prise en compte ; si les répliques contiennent des données différentes, vous obtiendrez également des données différentes.

​

Nom d’hôte le plus proche

load_balancing = nearest_hostname

Le nombre d’erreurs est compté pour chaque réplique. Toutes les 5 minutes, le nombre d’erreurs est divisé par 2 avec troncature à l’entier. Ainsi, le nombre d’erreurs est calculé sur une période récente avec un lissage exponentiel. S’il existe une réplique avec un nombre minimal d’erreurs (c.-à-d. que des erreurs se sont produites récemment sur les autres répliques), la requête lui est envoyée. S’il existe plusieurs répliques avec le même nombre minimal d’erreurs, la requête est envoyée à la réplique dont le nom d’hôte est le plus proche de celui du serveur dans le fichier de configuration (selon le nombre de caractères différents aux mêmes positions, jusqu’à la longueur minimale des deux noms d’hôte).

Par exemple, example01-01-1 et example01-01-2 diffèrent à une position, tandis que example01-01-1 et example01-02-2 diffèrent à deux positions. Cette méthode peut sembler rudimentaire, mais elle ne nécessite pas de données externes sur la topologie du réseau et elle ne compare pas les adresses IP, ce qui serait compliqué avec nos adresses IPv6.

Ainsi, s’il existe des répliques équivalentes, celle dont le nom est le plus proche est privilégiée. Nous pouvons également supposer que, lorsqu’une requête est envoyée au même serveur, en l’absence de défaillances, une requête distribuée ira elle aussi aux mêmes serveurs. Ainsi, même si les répliques contiennent des données différentes, la requête renverra globalement les mêmes résultats.

​

Distance de Levenshtein du nom d’hôte

load_balancing = hostname_levenshtein_distance

Comme nearest_hostname, mais compare le nom d’hôte à l’aide de la distance de Levenshtein. Par exemple :

example-clickhouse-0-0 ample-clickhouse-0-0
1

example-clickhouse-0-0 example-clickhouse-1-10
2

example-clickhouse-0-0 example-clickhouse-12-0
3

​

Plus long préfixe commun du nom d’hôte

load_balancing = hostname_longest_common_prefix

Comme nearest_hostname, mais la réplique dont le nom d’hôte partage le préfixe commun le plus long avec le nom d’hôte local est privilégiée (plus le préfixe commun est long, plus la priorité est élevée). Contrairement à nearest_hostname, qui compare les caractères différents position par position, cette stratégie n’est pas trompée par des noms d’hôte dont les segments numériques ont des longueurs différentes. Par exemple, pour le nom d’hôte local sfe301 :

sfe301 sde301
1

sfe301 sfe10101
3

sfe301 sde505
1

Ici, sfe10101 est préféré, car il partage avec sfe301 le préfixe commun le plus long (sfe, longueur 3).

Les répliques ayant la même longueur de préfixe commun sont choisies aléatoirement. En particulier, lorsqu’aucune réplique ne partage de préfixe avec le nom d’hôte local (toutes les longueurs de préfixe commun sont égales à zéro), cette stratégie se comporte exactement comme random.

​

Plus long suffixe commun du nom d’hôte

load_balancing = hostname_longest_common_suffix

Comme hostname_longest_common_prefix, mais on compare le plus long suffixe commun au lieu du préfixe. Cela est utile lorsque l’identité du centre de données est encodée dans le suffixe du nom d’hôte. Par exemple, pour le nom d’hôte local et46gtghn.qc.localdomain :

et46gtghn.qc.localdomain tr676ddgh.td.localdomain
12

et46gtghn.qc.localdomain ab999.qc.localdomain
15

Ici, ab999.qc.localdomain est privilégié, car il partage avec et46gtghn.qc.localdomain le suffixe commun le plus long (.qc.localdomain, longueur 15).

Les répliques ayant une longueur de suffixe commun identique sont choisies aléatoirement. En particulier, lorsqu’aucune réplique ne partage de suffixe avec le nom d’hôte local (toutes les longueurs de suffixe commun sont nulles), cette stratégie se comporte exactement comme random.

​

Dans l’ordre

load_balancing = in_order

Les répliques présentant le même nombre d’erreurs sont consultées dans le même ordre que celui dans lequel elles sont définies dans la configuration. Cette méthode convient lorsque vous savez exactement quelle réplique privilégier.

​

First or Random

load_balancing = first_or_random

Cet algorithme choisit la première réplique de l’ensemble, ou une réplique aléatoire si la première n’est pas disponible. Il est efficace dans les topologies de réplication croisée, mais inutile dans les autres configurations.

L’algorithme first_or_random résout le problème de l’algorithme in_order. Avec in_order, si une réplique tombe en panne, la suivante reçoit une charge doublée, tandis que les autres répliques continuent de gérer le volume de trafic habituel. Avec l’algorithme first_or_random, la charge est répartie uniformément entre les répliques encore disponibles.

Il est possible de définir explicitement quelle est la première réplique à l’aide du paramètre load_balancing_first_offset. Cela permet de mieux contrôler le rééquilibrage de la charge des requêtes entre les répliques.

​

Round Robin

load_balancing = round_robin

Cet algorithme utilise une stratégie round-robin entre les répliques ayant le même nombre d’erreurs (seules les requêtes utilisant la stratégie round_robin sont prises en compte).

​

load_balancing_first_offset

Réplique à laquelle envoyer de préférence une query lorsque la stratégie de load balancing FIRST_OR_RANDOM est utilisée.

​

load_marks_asynchronously

Charger les marks MergeTree de façon asynchrone

Valeur par défaut dans Cloud : 1.

​

local_filesystem_read_method

Méthode de lecture des données depuis le système de fichiers local, parmi : read, pread, mmap, io_uring, pread_threadpool.

La méthode ‘io_uring’ est expérimentale et ne fonctionne pas pour Log, TinyLog, StripeLog, File, Set et Join, ni pour les autres tables avec des fichiers auxquels on peut ajouter des données, en présence de lectures et d’écritures concurrentes. Si vous lisez divers articles sur ‘io_uring’ sur Internet, ne vous laissez pas aveugler par eux. Ce n’est pas une meilleure méthode de lecture des fichiers, sauf dans le cas d’un grand nombre de petites opérations d’E/S, ce qui n’est pas le cas dans ClickHouse. Il n’y a aucune raison d’activer ‘io_uring’.

​

local_filesystem_read_prefetch

Indique s’il faut utiliser le préchargement lors de la lecture de données à partir du système de fichiers local.

​

lock_acquire_timeout

Définit le nombre de secondes pendant lesquelles une demande de verrouillage attend avant d’échouer.

Le délai d’expiration du verrouillage est utilisé pour se prémunir contre les deadlocks lors de l’exécution d’opérations de lecture/écriture sur des tables. Lorsque ce délai expire et que la demande de verrouillage échoue, le serveur ClickHouse lève une exception « Locking attempt timed out! Possible deadlock avoided. Client should retry. » avec le code d’erreur DEADLOCK_AVOIDED.

Valeurs possibles :

• Entier positif (en secondes).
• 0 — Aucun délai d’expiration du verrouillage.

​

log_comment

Spécifie la valeur du champ log_comment de la table system.query_log, ainsi que le texte de commentaire du journal du serveur.

Il peut être utilisé pour améliorer la lisibilité des journaux du serveur. En outre, il permet de sélectionner les requêtes liées au test dans system.query_log après l’exécution de clickhouse-test.

Valeurs possibles :

• Toute chaîne de longueur inférieure ou égale à max_query_size. Si la valeur dépasse max_query_size, le serveur lève une exception.

Exemple

Requête :

SET log_comment = 'log_comment test', log_queries = 1;
SELECT 1;
SYSTEM FLUSH LOGS;
SELECT type, query FROM system.query_log WHERE log_comment = 'log_comment test' AND event_date >= yesterday() ORDER BY event_time DESC LIMIT 2;

Résultat :

┌─type────────┬─query─────┐
│ QueryStart  │ SELECT 1; │
│ QueryFinish │ SELECT 1; │
└─────────────┴───────────┘

​

log_formatted_queries

Permet d’enregistrer les requêtes formatées dans la table système system.query_log (renseigne la colonne formatted_query de system.query_log).

Valeurs possibles :

• 0 — Les requêtes formatées ne sont pas enregistrées dans la table système.
• 1 — Les requêtes formatées sont enregistrées dans la table système.

​

log_processors_profiles

Écrit dans la table system.processors_profile_log le temps passé par le processeur à s’exécuter ou à attendre des données.

Voir aussi :

• system.processors_profile_log
• EXPLAIN PIPELINE

​

log_profile_events

Consigne les statistiques de performance des requêtes dans query_log, query_thread_log et query_views_log.

​

log_queries

Active la journalisation des requêtes.

Les requêtes envoyées à ClickHouse avec ce paramètre sont journalisées conformément aux règles du paramètre de configuration du serveur query_log.

Exemple :

log_queries=1

​

log_queries_cut_to_length

Si la longueur de la requête dépasse le seuil spécifié (en octets), la requête est tronquée lors de son écriture dans le journal des requêtes. La longueur de la requête affichée dans le journal texte ordinaire est également limitée.

​

log_queries_min_query_duration_ms

Si ce paramètre est activé (non nul), les requêtes dont la durée est inférieure à la valeur définie ne seront pas journalisées (vous pouvez voir cela comme un long_query_time pour le journal des requêtes lentes de MySQL), ce qui signifie, en pratique, que vous ne les trouverez pas dans les tables suivantes :

• system.query_log
• system.query_thread_log

Seules les requêtes du type suivant seront consignées dans le journal :

• QUERY_FINISH

• EXCEPTION_WHILE_PROCESSING

• Type : millisecondes

• Valeur par défaut : 0 (toute requête)

​

log_queries_min_type

Type minimal à journaliser dans query_log.

Valeurs possibles :

• QUERY_START (=1)
• QUERY_FINISH (=2)
• EXCEPTION_BEFORE_START (=3)
• EXCEPTION_WHILE_PROCESSING (=4)

Peut être utilisé pour limiter les entités qui seront consignées dans query_log ; par exemple, si vous ne vous intéressez qu’aux erreurs, vous pouvez utiliser EXCEPTION_WHILE_PROCESSING :

log_queries_min_type='EXCEPTION_WHILE_PROCESSING'

​

log_queries_probability

Permet d’enregistrer dans les tables système query_log, query_thread_log et query_views_log uniquement un échantillon de requêtes sélectionnées aléatoirement selon la probabilité spécifiée. Cela permet de réduire la charge lorsqu’il y a un grand volume de requêtes par seconde.

Valeurs possibles :

• 0 — Les requêtes ne sont pas enregistrées dans les tables système.
• Nombre à virgule flottante positif compris dans l’intervalle [0..1]. Par exemple, si la valeur du paramètre est 0.5, environ la moitié des requêtes sont enregistrées dans les tables système.
• 1 — Toutes les requêtes sont enregistrées dans les tables système.

​

log_query_settings

Enregistre les paramètres de la requête dans query_log et dans le journal des spans OpenTelemetry.

​

log_query_threads

Active la journalisation des threads de requête.

Les threads de requête sont journalisés dans la table system.query_thread_log. Ce paramètre ne prend effet que lorsque log_queries vaut true. Les threads des requêtes exécutées par ClickHouse lorsque ce paramètre est activé sont journalisés selon les règles définies par le paramètre de configuration du serveur query_thread_log.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Exemple

log_query_threads=1

​

log_query_views

Active la journalisation des vues de requête.

Lorsqu’une requête exécutée par ClickHouse avec ce paramètre activé est associée à des vues (vues matérialisées ou live views), celles-ci sont journalisées dans le paramètre de configuration du serveur query_views_log.

Exemple :

log_query_views=1

​

low_cardinality_allow_in_native_format

Autorise ou limite l’utilisation du type de données LowCardinality avec le format Native.

Si l’utilisation de LowCardinality est limitée, serveur ClickHouse convertit les colonnes LowCardinality en colonnes ordinaires pour les requêtes SELECT, et les colonnes ordinaires en colonnes LowCardinality pour les requêtes INSERT.

Ce paramètre est principalement nécessaire pour les clients tiers qui ne prennent pas en charge le type de données LowCardinality.

Valeurs possibles :

• 1 — L’utilisation de LowCardinality n’est pas limitée.
• 0 — L’utilisation de LowCardinality est limitée.

​

low_cardinality_max_dictionary_size

Définit le nombre maximal de lignes d’un dictionnaire global partagé pour le type de données LowCardinality pouvant être écrit dans le système de fichiers de stockage. Ce paramètre permet d’éviter les problèmes de RAM en cas de croissance illimitée du dictionnaire. Toutes les données qui ne peuvent pas être encodées en raison de cette limite de taille du dictionnaire sont écrites par ClickHouse de façon classique.

Valeurs possibles :

• Tout entier positif.

​

low_cardinality_use_single_dictionary_for_part

Active ou désactive l’utilisation d’un dictionnaire unique pour une partie de données.

Par défaut, le serveur ClickHouse surveille la taille des dictionnaires et, si un dictionnaire dépasse sa limite, le serveur commence à écrire le suivant. Pour empêcher la création de plusieurs dictionnaires, définissez low_cardinality_use_single_dictionary_for_part = 1.

Valeurs possibles :

• 1 — La création de plusieurs dictionnaires pour la partie de données est interdite.
• 0 — La création de plusieurs dictionnaires pour la partie de données n’est pas interdite.

​

low_priority_query_wait_time_ms

Lorsque le mécanisme de priorisation des requêtes est utilisé (voir le paramètre priority), les requêtes de faible priorité attendent la fin des requêtes de priorité plus élevée. Ce paramètre définit cette durée d’attente.

​

make_distributed_plan

Génère un plan de requête distribuée.

​

materialize_skip_indexes_on_insert

Définit si les INSERT créent et stockent des index de saut. Si cette option est désactivée, les index de saut ne seront créés et stockés que lors des fusions ou via un MATERIALIZE INDEX explicite.

Voir aussi exclude_materialize_skip_indexes_on_insert.

​

materialize_statistics_on_insert

Indique si les INSERT créent et insèrent des statistiques. Si cette option est désactivée, les statistiques seront créées et stockées lors des fusions ou via un MATERIALIZE STATISTICS explicite

​

materialize_ttl_after_modify

Appliquer le TTL aux anciennes données après la requête ALTER MODIFY TTL

​

materialized_views_ignore_errors

Si ce paramètre est activé, les exceptions levées lors de l’envoi de données vers une vue matérialisée dépendante (dans son SELECT ou dans le sink de la table interne) sont consignées comme avertissement, et l’instruction INSERT réussit. S’il est désactivé (par défaut), une telle exception se propage et l’instruction INSERT échoue.

Ce paramètre contrôle uniquement le signalement des erreurs. Il n’annule pas une écriture dans la table source et ne garantit pas non plus que le block d’origine ait déjà été validé dans la table source lorsqu’une erreur survient dans le pipeline d’une vue dépendante. Lorsqu’il est désactivé (par défaut), l’INSERT échoue en cas d’erreur sur une vue — relancez-le avec la déduplication d’insertion (insert_deduplicate, deduplicate_blocks_in_dependent_materialized_views) pour une livraison exactly-once vers la table source et toutes les vues dépendantes. Lorsqu’il est activé, l’INSERT est signalé comme réussi malgré une livraison partielle aux vues en échec et à leurs chaînes en aval ; n’utilisez ce mode que lorsque les écritures dans la table source ne doivent pas être bloquées par des problèmes côté vue (par exemple, les tables system.*_log). Consultez la documentation CREATE VIEW pour obtenir la sémantique complète.

​

materialized_views_squash_parallel_inserts

Fusionne les inserts parallèles d’une même requête INSERT vers la table de destination des vues matérialisées afin de réduire le nombre de parts générées. Si cette valeur est définie sur false et que parallel_view_processing est activé, la requête INSERT générera une part dans la table de destination pour chaque max_insert_thread.

​

max_analyze_depth

Nombre maximal d’analyses réalisées par l’interpréteur.

​

max_ast_depth

La profondeur maximale d’imbrication de l’arbre syntaxique d’une requête. Si cette limite est dépassée, une exception est levée.

À l’heure actuelle, cette profondeur n’est pas contrôlée lors de l’analyse syntaxique, mais seulement après l’analyse de la requête. Cela signifie qu’un arbre syntaxique trop profond peut être créé pendant l’analyse syntaxique, mais la requête échouera.

​

max_ast_elements

Le nombre maximal d’éléments dans l’arbre syntaxique d’une requête. Si cette limite est dépassée, une exception est levée.

À l’heure actuelle, cette limite n’est pas vérifiée lors de l’analyse syntaxique, mais seulement après l’analyse de la requête. Cela signifie qu’un arbre syntaxique trop profond peut être créé pendant l’analyse syntaxique, mais que la requête échouera.

​

max_autoincrement_series

Limite du nombre de séries créées par la fonction generateSerialID.

Chaque série représentant un nœud dans Keeper, il est recommandé de ne pas en avoir plus de quelques millions.

​

bande_passante_max_backup

La vitesse de lecture maximale, en octets par seconde, pour une sauvegarde donnée sur le serveur. Zéro signifie qu’il n’y a pas de limite.

​

max_block_size

Dans ClickHouse, les données sont traitées par blocs, qui sont des ensembles de fragments de colonnes. Les cycles de traitement internes d’un bloc unique sont efficaces, mais le traitement de chaque bloc entraîne des surcoûts notables.

Le paramètre max_block_size indique le nombre maximal recommandé de lignes à inclure dans un bloc unique lors du chargement de données à partir de tables. Des blocs de la taille de max_block_size ne sont pas toujours chargés depuis la table : si ClickHouse détermine qu’il faut récupérer moins de données, un bloc plus petit est traité.

La taille du bloc ne doit pas être trop petite, afin d’éviter des surcoûts notables lors du traitement de chaque bloc. Elle ne doit pas non plus être trop grande, afin de garantir que les requêtes avec une clause LIMIT s’exécutent rapidement après le traitement du premier bloc. Lors du paramétrage de max_block_size, l’objectif est d’éviter une consommation excessive de mémoire lors de l’extraction d’un grand nombre de colonnes dans plusieurs threads, tout en préservant au moins un certain degré de localité de cache.

​

max_bytes_before_external_group_by

Valeur par défaut dans Cloud : la moitié de la mémoire disponible par 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é.

Si l’utilisation de la mémoire lors des opérations GROUP BY dépasse ce seuil en octets, activez le mode d’« agrégation externe » (écriture des données intermédiaires sur le disque).

La valeur recommandée est la moitié de la mémoire système disponible.

​

max_bytes_before_external_join

Si une valeur non nulle est définie et que join_algorithm vaut hash, parallel_hash, default ou auto, le hash join sera automatiquement converti en grace hash join afin d’autoriser le spilling sur disque lorsque les données du côté droit dépassent ce nombre d’octets. Lorsqu’il est défini sur 0 (valeur par défaut), ce seuil absolu en octets est désactivé, mais le spilling 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 spilling automatique. Cela empêche l’optimisation de lecture ordonnée 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é, des étapes supplémentaires de fusion de blocs sont effectuées avant la fusion finale afin de ne conserver que les LIMIT lignes en tête.

​

max_bytes_for_lazy_final

Nombre maximal d’octets de l’ensemble pour l’optimisation lazy de FINAL. Si cette valeur est dépassée, le système revient à FINAL normal.

​

max_bytes_in_distinct

Le nombre maximal d’octets de l’état (en octets non compressés) en mémoire utilisé par une table de hachage lors de l’utilisation de DISTINCT.

​

max_bytes_in_join

La taille maximale, en octets, de la structure de données du côté droit (généralement une table de hachage) utilisée pour les jointures 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. Lorsque la limite est atteinte, l’action dépend de l’algorithme join_algorithm choisi — consultez ce paramètre pour connaître le comportement propre à chaque algorithme (spill, repartitionnement, switch, ou throw/break selon join_overflow_mode).

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) utilisés par un ensemble de la clause IN créé à partir d’une sous-requête.

​

max_bytes_ratio_before_external_group_by

Part de la mémoire disponible pouvant être utilisée pour GROUP BY. Une fois cette limite atteinte, la mémoire externe est utilisée pour l’agrégation.

Par exemple, si elle 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, puis il commencera à utiliser l’agrégation externe.

​

max_bytes_ratio_before_external_join

Le 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écharger sur disque les données du côté droit.

Par exemple, si la valeur est définie sur 0.6, JOIN autorisera l’utilisation de 60% de la mémoire disponible (pour server/user/merges) pour la table de hachage du côté droit au début de l’exécution ; au-delà, le spilling sur disque commence.

Si max_bytes_before_external_join et max_bytes_ratio_before_external_join sont tous deux définis, le plus petit seuil obtenu est utilisé. Si le ratio est 0, seul le paramètre absolu s’applique.

N’a d’effet que lorsque join_algorithm vaut hash, parallel_hash, default ou auto, et qu’un chemin de données temporaires est configuré.

​

max_bytes_ratio_before_external_sort

La part de mémoire disponible pouvant être utilisée par ORDER BY. Une fois cette limite atteinte, un tri externe est utilisé.

Par exemple, si cette valeur est définie sur 0.6, ORDER BY pourra utiliser 60% de la mémoire disponible (pour le serveur/l’utilisateur/les fusions) au début de l’exécution ; ensuite, il commencera à utiliser un tri externe.

Notez que max_bytes_before_external_sort est toujours respecté : le spilling 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 interne et, lors d’une lecture depuis un serveur distant, n’est vérifiée que sur le serveur distant.

​

max_bytes_to_read_leaf

Le nombre maximal d’octets (de données non compressées) pouvant être lus depuis 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 ne sera vérifiée qu’à l’étape de lecture sur les nœuds feuille et sera ignorée lors de la 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é.

Ce paramètre est instable avec prefer_localhost_replica=1.

​

max_bytes_to_sort

Le nombre maximal d’octets avant le tri. Si plus que la quantité spécifiée d’octets non compressés doit être traitée pour l’opération ORDER BY, 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 server distant ou enregistrés dans une table temporaire lors de l’exécution de la section GLOBAL IN/JOIN.

​

max_columns_to_read

Le nombre maximal de colonnes pouvant être lues dans une table lors d’une seule requête. Si une requête nécessite de lire plus de colonnes que le nombre spécifié, une exception est levée.

Ce paramètre est utile pour éviter les requêtes trop complexes.

La valeur 0 signifie qu’il n’y a pas de limite.

​

max_compress_block_size

La taille maximale des blocs de données non compressées avant leur compression pour l’écriture dans une table. Par défaut, 1 048 576 (1 MiB). Indiquer une taille de bloc plus petite entraîne généralement une légère baisse du taux de compression ; la vitesse de compression et de décompression augmente légèrement grâce à une meilleure localité du cache, et la consommation de mémoire diminue.

Il s’agit d’un paramètre de niveau expert, et vous ne devriez pas le modifier si vous débutez avec ClickHouse.

Ne confondez pas les blocs utilisés pour la compression (un fragment de mémoire constitué d’octets) avec les blocs utilisés pour le traitement des requêtes (un ensemble de lignes d’une table).

​

max_concurrent_queries_for_all_users

Déclenche une exception si la valeur de ce paramètre est inférieure ou égale au nombre actuel de requêtes traitées simultanément.

Exemple : max_concurrent_queries_for_all_users peut être défini sur 99 pour tous les utilisateurs, et l’administrateur de la base de données peut le définir sur 100 pour lui-même afin de pouvoir exécuter des requêtes d’investigation même lorsque le serveur est surchargé.

La modification de ce paramètre pour une requête ou un utilisateur n’affecte pas les autres requêtes.

Valeurs possibles :

• Entier positif.
• 0 — Aucune limite.

Exemple

<max_concurrent_queries_for_all_users>99</max_concurrent_queries_for_all_users>

Voir aussi

• max_concurrent_queries

valeur par défaut dans Cloud : 1000.

​

max_concurrent_queries_for_user

Nombre maximal de requêtes traitées simultanément par utilisateur.

Valeurs possibles :

• Entier positif.
• 0 — Aucune limite.

Exemple

<max_concurrent_queries_for_user>5</max_concurrent_queries_for_user>

​

max_consume_snapshots

Nombre maximal de snapshots Paimon à consommer lors d’une lecture incrémentielle. 0 signifie qu’il n’y a pas de limite.

​

max_distributed_connections

Le nombre maximal de connexions simultanées aux serveurs distants pour le traitement distribué d’une seule requête sur une seule table Distributed. Nous recommandons de définir une valeur au moins égale au nombre de serveurs du cluster.

Les paramètres suivants ne sont utilisés que lors de la création de tables Distributed (et au démarrage d’un serveur) ; il n’y a donc aucune raison de les modifier à l’exécution.

​

max_distributed_depth

Limite la profondeur maximale des requêtes récursives pour les tables Distributed.

Si cette valeur est dépassée, le serveur lève une exception.

Valeurs possibles :

• Entier positif.
• 0 — Profondeur illimitée.

​

max_download_buffer_size

La taille maximale du tampon de téléchargement parallèle (par exemple pour le moteur URL) pour chaque thread.

​

max_download_threads

Le nombre maximal de threads pour le téléchargement de données (par exemple avec le moteur URL).

​

max_estimated_execution_time

Temps d’exécution estimé maximal de la requête, en secondes. Contrôlé sur chaque bloc de données à l’expiration de timeout_before_checking_execution_speed.

​

max_execution_speed

Le nombre maximal de lignes exécutées par seconde. Cette valeur est vérifiée sur chaque bloc de données lorsque timeout_before_checking_execution_speed expire. Si la vitesse d’exécution est trop élevée, elle sera réduite.

​

max_execution_speed_bytes

Nombre maximal d’octets traités par seconde. Cette limite est vérifiée sur chaque bloc de données lorsque timeout_before_checking_execution_speed expire. Si la vitesse d’exécution est trop élevée, elle sera réduite.

​

max_execution_time

Le temps d’exécution maximal de la requête, en secondes.

Le paramètre max_execution_time peut être un peu délicat à comprendre. Il fonctionne à partir d’une interpolation relative à la vitesse d’exécution actuelle de la requête (ce comportement est contrôlé par timeout_before_checking_execution_speed).

ClickHouse interrompt une requête si le temps d’exécution estimé dépasse la valeur de max_execution_time spécifiée. Par défaut, timeout_before_checking_execution_speed est défini sur 10 secondes. Cela signifie qu’après 10 secondes d’exécution de la requête, ClickHouse commence à estimer le temps d’exécution total. Si, par exemple, max_execution_time est défini sur 3600 secondes (1 heure), ClickHouse arrête la requête si la durée estimée dépasse cette limite de 3600 secondes. Si vous définissez timeout_before_checking_execution_speed sur 0, ClickHouse utilisera le temps écoulé comme base pour max_execution_time.

Si le temps d’exécution de la requête dépasse le nombre de secondes spécifié, le comportement est déterminé par timeout_overflow_mode, qui est défini par défaut sur throw.

Le délai d’expiration n’est vérifié, et la requête ne peut donc s’arrêter, qu’à certains points précis du traitement des données. Actuellement, elle ne peut pas s’arrêter pendant la fusion des états d’agrégation ni pendant l’analyse de la requête, et le temps d’exécution réel sera supérieur à la valeur de ce paramètre.

​

max_execution_time_leaf

Sémantiquement similaire à max_execution_time, mais s’applique uniquement aux nœuds feuilles pour les requêtes distribuées ou distantes.

Par exemple, si nous voulons limiter le temps d’exécution sur un nœud feuille à 10s sans imposer de limite sur le nœud initial, au lieu de définir max_execution_time dans les paramètres de la sous-requête imbriquée :

SELECT count()
FROM cluster(cluster, view(SELECT * FROM t SETTINGS max_execution_time = 10));

Nous pouvons utiliser max_execution_time_leaf dans les paramètres de la requête :

SELECT count()
FROM cluster(cluster, view(SELECT * FROM t)) SETTINGS max_execution_time_leaf = 10;

​

max_expanded_ast_elements

Taille maximale de l’arbre syntaxique de la requête, en nombre de nœuds, après développement des alias et de l’astérisque.

​

max_fetch_partition_retries_count

Nombre de tentatives pour récupérer une partition depuis un autre hôte.

​

max_final_threads

Définit le nombre maximal de threads parallèles pour la phase de lecture des données de la requête SELECT avec le modificateur FINAL.

Valeurs possibles :

• Entier positif.
• 0 ou 1 — Désactivé. Les requêtes SELECT sont exécutées sur un seul thread.

​

max_http_get_redirects

Nombre maximal de sauts de redirection HTTP GET autorisés. Garantit la mise en place de mesures de sécurité supplémentaires pour empêcher un serveur malveillant de rediriger vos requêtes vers des services inattendus.\n\nCela se produit lorsqu’un serveur externe redirige vers une autre adresse, mais que cette adresse semble appartenir à l’infrastructure interne de l’entreprise. En envoyant une requête HTTP à un serveur interne, vous pourriez alors appeler une API interne depuis le réseau interne, contourner l’authentification, voire interroger d’autres services, tels que Redis ou Memcached. Si vous n’avez pas d’infrastructure interne (y compris un service exécuté sur votre localhost) ou si vous faites confiance au serveur, vous pouvez autoriser les redirections sans risque. Gardez toutefois à l’esprit que, si l’URL utilise HTTP plutôt que HTTPS, vous devrez faire confiance non seulement au serveur distant, mais aussi à votre FAI et à tous les réseaux intermédiaires.

valeur par défaut dans Cloud : 10.

​

max_hyperscan_regexp_length

Définit la longueur maximale autorisée pour chaque expression régulière dans les fonctions hyperscan multi-match.

Valeurs possibles :

• Entier positif.
• 0 - La longueur n’est pas limitée.

Exemple

Requête :

SELECT multiMatchAny('abcd', ['ab','bcd','c','d']) SETTINGS max_hyperscan_regexp_length = 3;

Résultat :

┌─multiMatchAny('abcd', ['ab', 'bcd', 'c', 'd'])─┐
│                                              1 │
└────────────────────────────────────────────────┘

Requête :

SELECT multiMatchAny('abcd', ['ab','bcd','c','d']) SETTINGS max_hyperscan_regexp_length = 2;

Résultat :

Exception: Regexp length too large.

Voir aussi

• max_hyperscan_regexp_total_length

​

max_hyperscan_regexp_total_length

Définit la longueur totale maximale de toutes les expressions régulières pour chaque fonction hyperscan multi-match.

Valeurs possibles :

• Entier positif.
• 0 - La longueur n’est pas limitée.

Exemple

Requête :

SELECT multiMatchAny('abcd', ['a','b','c','d']) SETTINGS max_hyperscan_regexp_total_length = 5;

Résultat :

┌─multiMatchAny('abcd', ['a', 'b', 'c', 'd'])─┐
│                                           1 │
└─────────────────────────────────────────────┘

Requête :

SELECT multiMatchAny('abcd', ['ab','bc','c','d']) SETTINGS max_hyperscan_regexp_total_length = 5;

Résultat :

Exception: Total regexp lengths too large.

Voir aussi

• max_hyperscan_regexp_length

​

max_insert_block_size

Alias : max_insert_block_size_rows

La taille maximale des blocs (en nombre de lignes) à former pour l’insertion dans une table.

Ce paramètre contrôle la formation des blocs dans deux contextes :

1. Analyse des formats : lorsque le serveur analyse des formats d’entrée basés sur les lignes (CSV, TSV, JSONEachRow, etc.) depuis n’importe quelle interface (HTTP, clickhouse-client avec des données intégrées, gRPC, protocole wire PostgreSQL), les blocs sont émis lorsque :

   • Les deux seuils min_insert_block_size_rows AND min_insert_block_size_bytes sont atteints, OR
   • L’un des seuils max_insert_block_size_rows OR max_insert_block_size_bytes est atteint

   Remarque : lors de l’utilisation de clickhouse-client ou clickhouse-local pour lire depuis un fichier, le client analyse lui-même les données, et ce paramètre s’applique côté client.

2. Opérations INSERT : pendant les requêtes INSERT et lorsque les données transitent par des vues matérialisées, le comportement de ce paramètre dépend de use_strict_insert_block_limits :

   • Lorsqu’il est activé : les blocs sont émis lorsque :

     • Seuils minimums (AND) : les deux seuils min_insert_block_size_rows AND min_insert_block_size_bytes sont atteints
     • Seuils maximums (OR) : l’un des seuils max_insert_block_size_rows OR max_insert_block_size_bytes est atteint

   • Lorsqu’il est désactivé : les blocs sont émis lorsque min_insert_block_size_rows OR min_insert_block_size_bytes est atteint. Les paramètres max_insert_block_size ne sont pas appliqués.

Valeurs possibles :

• Entier positif.

​

max_insert_block_size_bytes

Taille maximale, en octets, des blocs à former pour l’insertion dans une table.

Ce paramètre fonctionne de concert avec max_insert_block_size_rows et contrôle la formation des blocs dans le même contexte. Voir max_insert_block_size_rows pour des informations détaillées sur le moment et la manière dont ces paramètres sont appliqués.

Valeurs possibles :

• Entier positif.
• 0 — le paramètre ne participe pas à la formation des blocs.

​

max_insert_delayed_streams_for_parallel_write

Le nombre maximal de flux (colonnes) pour lesquels retarder le flush final de la part. Valeur par défaut : auto (100 si le stockage sous-jacent prend en charge l’écriture parallèle, par exemple S3, et désactivé sinon)

Valeur par défaut Cloud : 50.

​

max_insert_threads

Le nombre maximal de threads pour exécuter la requête INSERT SELECT.

Valeurs possibles :

• 0 (ou 1) — aucune exécution en parallèle de INSERT SELECT.
• Entier positif, supérieur à 1.

Valeur par défaut dans Cloud :

• 1 pour les nœuds disposant de 8 Gio de mémoire
• 2 pour les nœuds disposant de 16 Gio de mémoire
• 4 pour les nœuds plus grands

L’exécution en parallèle de INSERT SELECT n’a d’effet que si la partie SELECT est elle aussi exécutée en parallèle ; voir le paramètre max_threads. Des valeurs plus élevées entraînent une utilisation de la mémoire plus importante.

​

max_insert_threads_min_free_memory_per_thread

Identique à max_threads_min_free_memory_per_thread, mais appliqué à max_insert_threads au lieu de max_threads. La valeur par défaut est plus élevée, car les pipelines d’insertion utilisent généralement des tampons par thread plus volumineux (parties MergeTree, blocs de compression) que les pipelines de lecture.

Si la quantité de mémoire libre est inférieure à max_insert_threads multiplié par cette valeur, max_insert_threads est réduit en conséquence, avec un minimum de 1.

Définissez cette valeur sur 0 pour désactiver cette limite.

​

max_joined_block_size_bytes

Taille maximale du bloc, en octets, pour le résultat du JOIN (si l’algorithme de jointure le prend en charge). 0 signifie sans limite.

​

max_joined_block_size_rows

Taille maximale du bloc pour le résultat du JOIN (si l’algorithme de jointure le prend en charge). 0 signifie sans limite.

​

max_limit_for_vector_search_queries

Les requêtes SELECT dont le LIMIT est supérieur à ce paramètre ne peuvent pas utiliser les index de similarité vectorielle. Cela permet d’éviter les dépassements de capacité mémoire dans les index de similarité vectorielle.

​

max_local_read_bandwidth

Le débit maximal de lecture locale en octets par seconde.

​

max_local_write_bandwidth

Le débit maximal des écritures locales, en octets par seconde.

​

max_memory_usage

Valeur par défaut dans Cloud : dépend de la quantité de RAM sur la réplique.

Quantité maximale de RAM pouvant être utilisée pour exécuter une requête sur un seul serveur. Une valeur de 0 signifie qu’il n’y a pas de limite.

Ce paramètre ne tient pas compte de la quantité de mémoire disponible ni de la quantité totale de mémoire sur la machine. La restriction s’applique à une seule requête sur un seul serveur.

Vous pouvez utiliser SHOW PROCESSLIST pour voir la consommation de mémoire actuelle de chaque requête. Le pic de consommation mémoire est suivi pour chaque requête et consigné dans le journal.

L’utilisation de la mémoire n’est pas entièrement suivie pour les états des fonctions d’agrégation suivantes lorsque leurs arguments sont de type String et Array :

• min
• max
• any
• anyLast
• argMin
• argMax

La consommation de mémoire est également limitée par les paramètres max_memory_usage_for_user et max_server_memory_usage.

​

max_memory_usage_for_user

La quantité maximale de RAM pouvant être utilisée pour exécuter les requêtes d’un utilisateur sur un seul serveur. Zéro signifie illimité.

Par défaut, cette quantité n’est pas limitée (max_memory_usage_for_user = 0).

Voir aussi la description de max_memory_usage.

Par exemple, si vous souhaitez définir max_memory_usage_for_user à 1000 octets pour un utilisateur nommé clickhouse_read, vous pouvez utiliser l’instruction

ALTER USER clickhouse_read SETTINGS max_memory_usage_for_user = 1000;

Vous pouvez vérifier que cela a bien fonctionné en vous déconnectant de votre client, en vous reconnectant, puis en utilisant la fonction getSetting :

SELECT getSetting('max_memory_usage_for_user');

​

max_network_bandwidth

Limite le débit des échanges de données sur le réseau en octets par seconde. Ce paramètre s’applique à chaque requête.

Valeurs possibles :

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

​

max_network_bandwidth_for_all_users

Limite le débit d’échange des données sur le réseau, en octets par seconde. Ce paramètre s’applique à toutes les requêtes exécutées simultanément sur le serveur.

Valeurs possibles :

• Entier positif.
• 0 — Le contrôle du débit des données est désactivé.

​

max_network_bandwidth_for_user

Limite le débit du transfert de données sur le réseau en octets par seconde. Ce paramètre s’applique à toutes les requêtes exécutées simultanément par un seul utilisateur.

Valeurs possibles :

• Entier positif.
• 0 — Le contrôle du débit des données est désactivé.

​

max_network_bytes

Limite le volume de données (en octets) reçu ou transmis sur le réseau lors de l’exécution d’une requête. Ce paramètre s’applique à chaque requête prise individuellement.

Valeurs possibles :

• Entier positif.
• 0 — Le contrôle du volume de données est désactivé.

​

max_number_of_partitions_for_independent_aggregation

Nombre maximal de partitions de la table pour appliquer l’optimisatio

​

max_os_cpu_wait_time_ratio_to_throw

Rapport maximal entre les temps d’attente CPU du système d’exploitation (métrique OSCPUWaitMicroseconds) et d’activité (métrique OSCPUVirtualTimeMicroseconds), au-delà duquel des requêtes peuvent être rejetées. Une interpolation linéaire entre les rapports minimal et maximal est utilisée pour calculer la probabilité ; à ce point, elle est égale à 1.

​

max_parallel_replicas

Le nombre maximal de répliques pour chaque shard lors de l’exécution d’une requête.

Valeurs possibles :

• Entier positif.

Informations supplémentaires

Cette option peut produire des résultats différents selon les paramètres utilisés.

​

Traitement parallèle avec la clé SAMPLE

Une requête peut être traitée plus rapidement si elle est exécutée en parallèle sur plusieurs serveurs. Mais les performances des requêtes peuvent se dégrader dans les cas suivants :

• La position de la clé d’échantillonnage dans la clé de partitionnement ne permet pas d’effectuer efficacement des parcours de plages.
• L’ajout d’une clé d’échantillonnage à la table rend moins efficace le filtrage sur d’autres colonnes.
• La clé d’échantillonnage est une expression coûteuse à calculer.
• La distribution de la latence du cluster a une longue traîne, de sorte qu’interroger davantage de serveurs augmente la latence globale de la requête.

​

Traitement parallèle avec parallel_replicas_custom_key

Ce paramètre est utile pour toute table répliquée.

​

max_parser_backtracks

Nombre maximal de retours en arrière du parseur syntaxique (nombre de fois où il essaie différentes alternatives au cours du processus d’analyse descendante récursive).

​

max_parser_depth

Limite la profondeur de récursion maximale du parseur à descente récursive. Permet de contrôler la taille de la pile.

Valeurs possibles :

• Entier positif.
• 0 — La profondeur de récursion est illimitée.

​

max_parsing_threads

Le nombre maximal de threads utilisés pour analyser les données dans les formats d’entrée prenant en charge l’analyse en parallèle. Par défaut, cette valeur est déterminée automatiquement.

​

max_partition_size_to_drop

Limitation de la suppression de partitions à l’exécution de la requête. La valeur 0 signifie que vous pouvez supprimer des partitions sans aucune restriction.

Valeur par défaut Cloud : 1 TB.

Ce paramètre de requête remplace le paramètre serveur équivalent, voir max_partition_size_to_drop

​

max_partitions_per_insert_block

Limite le nombre maximal de partitions dans un seul bloc inséré et une exception est levée si le bloc contient trop de partitions.

• Entier positif.
• 0 — Nombre illimité de partitions.

Détails

Lors de l’insertion de données, ClickHouse calcule le nombre de partitions dans le bloc inséré. Si le nombre de partitions dépasse max_partitions_per_insert_block, ClickHouse consigne soit un avertissement, soit lève une exception selon throw_on_max_partitions_per_insert_block. Les exceptions ont le texte suivant :

“Trop de partitions pour un seul bloc INSERT (partitions_count partitions, la limite est ” + toString(max_partitions) + ”). La limite est contrôlée par le paramètre ‘max_partitions_per_insert_block’. Un grand nombre de partitions est une erreur de conception fréquente. Cela entraînera un fort impact négatif sur les performances, notamment un démarrage lent du serveur, des requêtes INSERT lentes et des requêtes SELECT lentes. Le nombre total recommandé de partitions pour une table est inférieur à 1000..10000. Veuillez noter que le partitionnement n’est pas destiné à accélérer les requêtes SELECT (la clé ORDER BY suffit à rendre les requêtes par plage rapides). Les partitions sont destinées à la manipulation des données (DROP PARTITION, etc.).”

Ce paramètre constitue un seuil de sécurité, car l’utilisation d’un grand nombre de partitions est une erreur de conception fréquente.

​

max_partitions_to_read

Limite le nombre maximal de partitions accessibles dans une seule requête.

La valeur du paramètre spécifiée lors de la création de la table peut être remplacée par un paramètre défini au niveau de la requête.

Valeurs possibles :

• Entier positif
• -1 - illimité (par défaut)

Vous pouvez également spécifier le paramètre MergeTree max_partitions_to_read dans les paramètres de la table.

​

max_parts_to_move

Limite le nombre de parties pouvant être déplacées en une seule requête. Zéro signifie qu’il n’y a pas de limite.

​

max_projection_rows_to_use_projection_index

Si le nombre de lignes à lire depuis l’index de projection est inférieur ou égal à ce seuil, ClickHouse essaiera d’utiliser l’index de projection lors de l’exécution de la requête.

​

max_query_size

Nombre maximal d’octets d’une query string analysée par le parseur SQL. Les données de la clause VALUES des requêtes INSERT sont traitées par un parseur de flux distinct (qui consomme O(1) de RAM) et ne sont pas affectées par cette restriction.

max_query_size ne peut pas être défini dans une requête SQL (par ex., SELECT now() SETTINGS max_query_size=10000) car ClickHouse doit allouer un buffer pour analyser la requête, et la taille de ce buffer est déterminée par le paramètre max_query_size, qui doit être configuré avant l’exécution de la requête.

​

max_rand_distribution_parameter

Valeur maximale des paramètres de forme des distributions dans les fonctions de distribution aléatoire telles que randChiSquared, randStudentT et randFisherF. Cela évite des temps de calcul excessivement longs avec des valeurs de paramètres extrêmes.

​

max_rand_distribution_trials

Nombre maximal d’essais autorisés pour les fonctions de distribution aléatoire telles que randBinomial et randNegativeBinomial. Cela évite des temps de calcul extrêmement longs lorsque le nombre d’essais est très élevé.

​

max_read_buffer_size

La taille maximale du tampon de lecture depuis le système de fichiers.

​

max_read_buffer_size_local_fs

La taille maximale du tampon de lecture à partir du système de fichiers local. Si elle est définie sur 0, max_read_buffer_size sera utilisé.

​

max_read_buffer_size_remote_fs

La taille maximale du tampon de lecture depuis le système de fichiers distant. Si elle est définie sur 0, max_read_buffer_size sera utilisé.

​

max_recursive_cte_evaluation_depth

Profondeur maximale d’évaluation des CTE récursives

​

max_remote_read_network_bandwidth

Le débit maximal de transfert de données sur le réseau, en octets par seconde, pour la lecture.

​

max_remote_write_network_bandwidth

La vitesse maximale d’échange de données sur le réseau, en octets par seconde, pour l’écriture.

​

max_replica_delay_for_distributed_queries

Exclut les répliques en retard des requêtes distribuées. Voir Réplication.

Définit une durée en secondes. Si le retard d’une réplique est supérieur ou égal à la valeur définie, cette réplique n’est pas utilisée.

Valeurs possibles :

• Entier positif.
• 0 — Le retard des répliques n’est pas vérifié.

Pour empêcher l’utilisation de toute réplique avec un retard non nul, définissez ce paramètre sur 1.

Utilisé lors de l’exécution d’un SELECT sur une table distribuée pointant vers des tables répliquées.

​

max_result_bytes

Limite la taille du résultat en octets (non compressés). La requête s’arrête après le traitement d’un bloc de données si le seuil est atteint, mais elle ne tronque pas le dernier bloc du résultat ; la taille du résultat peut donc être supérieure au seuil.

Points à noter

La taille du résultat en mémoire est prise en compte pour ce seuil. Même si la taille du résultat est faible, il peut faire référence à des structures de données plus volumineuses en mémoire, comme des dictionnaires de colonnes LowCardinality et des Arenas de colonnes AggregateFunction ; le seuil peut donc être dépassé malgré la faible taille du résultat.

Ce paramètre est de bas niveau et doit être utilisé avec précaution

​

max_result_rows

Valeur par défaut dans Cloud : 0.

Limite le nombre de lignes du résultat. Cette limite est également vérifiée pour les sous-requêtes, ainsi que sur les serveurs distants lors de l’exécution de parties d’une requête distribuée. Aucune limite n’est appliquée lorsque la valeur est 0.

La requête s’arrête après le traitement d’un bloc de données si le seuil est atteint, mais le dernier bloc du résultat n’est pas tronqué. La taille du résultat peut donc être supérieure au seuil.

​

max_reverse_dictionary_lookup_cache_size_bytes

Taille maximale, en octets, du cache de lookup inverse du dictionnaire par requête utilisé par la fonction dictGetKeys. Le cache stocke des tuples de clés sérialisés par valeur d’attribut afin d’éviter de parcourir à nouveau le dictionnaire au sein d’une même requête. Lorsque la limite est atteinte, les entrées sont évacuées selon la politique LRU. Définissez cette valeur sur 0 pour désactiver la mise en cache.

​

max_rows_for_lazy_final

Nombre maximal de lignes dans l’ensemble pour l’optimisation lazy FINAL. En cas de dépassement, bascule sur FINAL normal.

​

max_rows_in_distinct

Le nombre maximal de lignes distinctes lors de l’utilisation de DISTINCT.

​

max_rows_in_join

Limite le nombre de lignes dans la structure de données 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 ainsi qu’au moteur de table Join.

Si une query contient plusieurs jointures, ClickHouse vérifie ce paramètre pour chaque résultat intermédiaire. Lorsque la limite est atteinte, l’action dépend du join_algorithm choisi — voir ce paramètre pour le comportement propre à chaque algorithme (spill, repartitionnement, basculement ou throw/break selon join_overflow_mode).

Valeurs possibles :

• Entier positif.
• 0 — Nombre de lignes illimité.

​

max_rows_in_set

Nombre maximal de lignes d’un ensemble de données dans la clause IN créée à partir d’une sous-requête.

​

max_rows_in_set_to_optimize_join

Taille maximale de l’ensemble utilisé pour filtrer les tables jointes à partir des ensembles de lignes de chacune avant la jointure.

Valeurs possibles :

• 0 — Désactiver.
• Tout entier positif.

​

max_rows_to_group_by

Le nombre maximal de clés uniques reçues lors de l’agrégation. Ce paramètre vous permet de limiter la consommation de mémoire lors de l’agrégation.

Si l’agrégation pendant GROUP BY génère plus que le nombre spécifié de lignes (clés GROUP BY uniques), le comportement sera déterminé par ‘group_by_overflow_mode’, qui vaut par défaut throw, mais peut aussi être basculé vers un mode GROUP BY approximatif.

​

max_rows_to_read

Le nombre maximal de lignes pouvant être lues depuis 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 profonde et, lors de la lecture depuis un serveur distant, n’est vérifiée que sur le serveur distant.

​

max_rows_to_read_leaf

Nombre maximal de lignes pouvant être lues depuis 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 elle 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 de 100 lignes. La requête distribuée destinée à lire toutes les données des deux tables avec le paramètre max_rows_to_read=150 échouera, car le total sera de 200 lignes. Une requête avec max_rows_to_read_leaf=150 aboutira, puisque les nœuds feuille liront au maximum 100 lignes.

La restriction est vérifiée pour chaque fragment de données traité.

Ce paramètre est instable avec prefer_localhost_replica=1.

​

max_rows_to_sort

Le nombre maximal de lignes avant tri. Cela permet de limiter la consommation de mémoire lors du tri. Si le nombre d’enregistrements à traiter pour l’opération ORDER BY dépasse la valeur spécifiée, le comportement sera déterminé par sort_overflow_mode, qui est défini par défaut sur throw.

​

max_rows_to_transfer

Nombre maximal de lignes pouvant être transmises à un serveur distant ou enregistrées dans une table temporaire lors de l’exécution de la section GLOBAL IN/JOIN.

​

max_sessions_for_user

Nombre maximal de sessions simultanées pour chaque utilisateur authentifié sur le serveur ClickHouse.

Exemple :

<profiles>
    <single_session_profile>
        <max_sessions_for_user>1</max_sessions_for_user>
    </single_session_profile>
    <two_sessions_profile>
        <max_sessions_for_user>2</max_sessions_for_user>
    </two_sessions_profile>
    <unlimited_sessions_profile>
        <max_sessions_for_user>0</max_sessions_for_user>
    </unlimited_sessions_profile>
</profiles>
<users>
    <!-- User Alice can connect to a ClickHouse server no more than once at a time. -->
    <Alice>
        <profile>single_session_user</profile>
    </Alice>
    <!-- User Bob can use 2 simultaneous sessions. -->
    <Bob>
        <profile>two_sessions_profile</profile>
    </Bob>
    <!-- User Charles can use arbitrarily many of simultaneous sessions. -->
    <Charles>
        <profile>unlimited_sessions_profile</profile>
    </Charles>
</users>

Valeurs possibles :

• Entier positif
• 0 - nombre illimité de sessions simultanées (par défaut)

​

max_size_to_preallocate_for_aggregation

Nombre d’éléments pour lesquels il est permis de préallouer de l’espace dans l’ensemble des tables de hachage avant l’agrégatio

​

max_size_to_preallocate_for_joins

Nombre d’éléments pour lesquels il est permis de préallouer de l’espace, au total, dans toutes les tables de hachage avant joi

​

max_skip_unavailable_shards_num

Lorsque skip_unavailable_shards est activé, ce paramètre limite le nombre maximal de shards pouvant être ignorés silencieusement. Si le nombre de shards indisponibles dépasse cette valeur, une exception est levée au lieu de les ignorer silencieusement.

Une valeur de 0 signifie qu’il n’y a pas de limite (comportement par défaut — tous les shards indisponibles peuvent être ignorés).

​

max_skip_unavailable_shards_ratio

Lorsque skip_unavailable_shards est activé, limite la proportion maximale (de 0 à 1) de shards pouvant être ignorés silencieusement. Si la proportion de shards indisponibles par rapport au nombre total de shards dépasse cette valeur, une exception est levée au lieu de les ignorer silencieusement.

Une valeur de 0 signifie qu’il n’y a pas de limite (comportement par défaut — tous les shards indisponibles peuvent être ignorés).

​

max_streams_for_files_processing_in_cluster_functions

S’il n’est pas nul, limite le nombre de threads qui lisent des données depuis des fichiers dans les fonctions de table cluster.

​

max_streams_for_merge_tree_reading

Si cette valeur n’est pas nulle, elle limite le nombre de flux de lecture pour la table MergeTree.

​

max_streams_for_union_step

Limite le nombre de flux de données actifs simultanément dans une étape UNION (s’applique à la fois à UNION ALL et à UNION DISTINCT, car UNION DISTINCT est implémenté via une étape UNION ALL suivie d’une étape DISTINCT). Lorsqu’une requête UNION comporte de nombreuses sous-requêtes, elles ouvrent toutes leurs tampons de lecture en même temps, ce qui entraîne une utilisation de la mémoire proportionnelle au nombre de sous-requêtes. Ce paramètre insère des processeurs Concat pour resserrer le pipeline afin qu’au plus ce nombre de flux soit actif à un instant donné, réduisant ainsi fortement le pic de mémoire. La limite réelle est le minimum entre cette valeur et max_threads * max_streams_for_union_step_to_max_threads_ratio (si l’une ou l’autre vaut 0, elle est ignorée). Lorsque les deux valent 0, aucun resserrement n’est appliqué. La limite n’est pas non plus appliquée lorsque le plan de requête exige que chaque flux de sortie du UNION reste trié individuellement (par exemple, lorsque l’optimisation de lecture dans l’ordre est appliquée au UNION) ; dans ce cas, le respect de l’ordre prévaut et le resserrement est ignoré.

​

max_streams_for_union_step_to_max_threads_ratio

Ce ratio, multiplié par max_threads, détermine une limite du nombre de flux actifs simultanément dans une étape UNION (s’applique à la fois à UNION ALL et à UNION DISTINCT). La limite réelle est le minimum entre cette valeur calculée et max_streams_for_union_step (si l’un des deux vaut 0, il est ignoré). Par exemple, avec max_threads = 8 et ce ratio défini sur 1, au plus 8 flux seront actifs. Définissez-le sur 0 pour désactiver cette limite basée sur le ratio. Comme pour max_streams_for_union_step, la limite n’est pas appliquée lorsque le plan de requête exige que chaque flux de sortie du UNION reste trié individuellement.

​

max_streams_multiplier_for_merge_tables

Demande un plus grand nombre de flux lors de la lecture depuis une Merge table. Les flux seront répartis entre les tables utilisées par la Merge table. Cela permet de mieux équilibrer la charge de travail entre les threads et s’avère particulièrement utile lorsque les tables sous-jacentes n’ont pas la même taille.

​

max_streams_to_max_threads_ratio

Permet d’utiliser plus de sources que de threads afin de répartir le travail plus uniformément entre eux. Il s’agit vraisemblablement d’une solution temporaire, car il sera possible à l’avenir de faire en sorte que le nombre de sources soit égal au nombre de threads, tout en permettant à chaque source de sélectionner dynamiquement le travail disponible.

​

max_subquery_depth

Si une requête comporte plus que le nombre spécifié de sous-requêtes imbriquées, une exception est levée.

Cela permet d’effectuer une vérification de cohérence afin d’empêcher les utilisateurs de votre cluster d’écrire des requêtes excessivement complexes.

​

max_table_size_to_drop

Restriction sur la suppression de tables au moment de l’exécution de la requête. La valeur 0 signifie que vous pouvez supprimer toutes les tables sans aucune restriction.

Valeur par défaut dans Cloud : 1 TB.

Ce paramètre de requête remplace le paramètre de serveur équivalent. Voir max_table_size_to_drop

​

max_temporary_columns

Le nombre maximal de colonnes temporaires qui peuvent être conservées simultanément en RAM lors de l’exécution d’une requête, y compris les colonnes constantes. Si une requête génère en mémoire plus de colonnes temporaires que le nombre spécifié à la suite d’un calcul intermédiaire, une exception est levée.

Ce paramètre est utile pour éviter les requêtes trop complexes.

La valeur 0 signifie qu’il n’y a pas de limite.

​

max_temporary_data_on_disk_size_for_query

La quantité maximale de données utilisée par les fichiers temporaires sur le disque, en octets, pour l’ensemble des requêtes exécutées simultanément.

Valeurs possibles :

• Entier positif.
• 0 — illimité (par défaut)

​

max_temporary_data_on_disk_size_for_user

La quantité maximale de données consommées, en octets, par les fichiers temporaires sur le disque pour l’ensemble des requêtes utilisateur exécutées simultanément.

Valeurs possibles :

• Entier positif.
• 0 — illimité (par défaut)

​

max_temporary_non_const_columns

Comme max_temporary_columns, il s’agit du nombre maximal de colonnes temporaires à conserver simultanément en RAM lors de l’exécution d’une requête, sans compter les colonnes constantes.

Des colonnes constantes sont assez fréquemment générées lors de l’exécution d’une requête, mais elles ne nécessitent pratiquement aucune ressource de calcul.

​

max_threads

Le nombre maximal de threads de traitement des requêtes, à l’exclusion des threads utilisés pour récupérer des données depuis des serveurs distants (voir le paramètre ‘max_distributed_connections’).

Ce paramètre s’applique aux threads qui exécutent en parallèle les mêmes étapes du pipeline de traitement des requêtes. Par exemple, lors de la lecture d’une table, s’il est possible d’évaluer en parallèle des expressions avec des fonctions, de filtrer avec WHERE et de pré-agréger pour GROUP BY en utilisant au moins ‘max_threads’ threads, alors ‘max_threads’ threads sont utilisés.

Pour les requêtes qui se terminent rapidement à cause d’un LIMIT, vous pouvez définir une valeur plus faible pour ‘max_threads’. Par exemple, si le nombre nécessaire d’entrées se trouve dans chaque bloc et que max_threads = 8, alors 8 blocs sont récupérés, alors qu’il aurait suffi d’en lire un seul. Plus la valeur de max_threads est faible, moins la mémoire consommée est importante.

Par défaut, le paramètre max_threads correspond au nombre de threads matériels (nombre de cœurs CPU) disponibles pour ClickHouse. Cas particulier : pour les processeurs x86 disposant de moins de 32 cœurs CPU et du SMT (par ex. Intel HyperThreading), ClickHouse utilise par défaut le nombre de cœurs logiques (= 2 x le nombre de cœurs physiques).

Sans SMT (par ex. Intel HyperThreading), cela correspond au nombre de cœurs CPU.

Pour les utilisateurs de ClickHouse Cloud, la valeur par défaut s’affiche sous la forme auto(N), où N correspond à la taille vCPU de votre service, par ex. 2vCPU/8GiB, 4vCPU/16GiB, etc. Consultez l’onglet Settings dans la Cloud Console pour obtenir la liste de toutes les tailles de service.

​

max_threads_for_indexes

Le nombre maximal de threads utilisés pour traiter les index.

​

max_threads_min_free_memory_per_thread

Réduit max_threads lorsque le serveur est sous pression mémoire, afin d’éviter de lancer des requêtes fortement parallèles susceptibles d’atteindre la limite de mémoire.

La mémoire libre est calculée comme max_server_memory_usage du serveur moins la mémoire actuellement suivie par le memory tracker global. Si cette mémoire libre est inférieure à max_threads multiplié par cette valeur, max_threads est réduit au plus grand N tel que N * value <= free_memory, avec un minimum de 1.

Définissez cette valeur sur 0 pour désactiver cette limite.

Par exemple, avec la valeur par défaut de 1 GiB et 32 GiB de mémoire libre, max_threads est plafonné à 32 ; avec 1 GiB de mémoire libre, il retombe à 1.

Ce paramètre s’applique au parallélisme côté lecture (SELECT, UNION, INTERSECT/EXCEPT et la partie SELECT de INSERT ... SELECT). Pour le côté écriture, voir max_insert_threads_min_free_memory_per_thread.

​

max_untracked_memory

Les petites allocations et désallocations sont regroupées dans une variable locale de thread et suivies ou profilées uniquement lorsqu’une quantité (en valeur absolue) devient supérieure à la valeur spécifiée. Si la valeur est supérieure à ‘memory_profiler_step’, elle sera effectivement ramenée à ‘memory_profiler_step’.

​

max_wkb_geometry_elements

Nombre maximal de points, d’anneaux ou de polygones autorisés dans un même élément de géométrie WKB lors de l’analyse par readWKB et les fonctions associées. Cela protège contre des allocations mémoire excessives causées par des données WKB malformées. Définissez cette valeur sur 0 pour utiliser la limite codée en dur (100 millions).

​

memory_overcommit_ratio_denominator

Il représente la limite souple de mémoire lorsque la limite stricte est atteinte au niveau global. Cette valeur est utilisée pour calculer le ratio de surallocation pour la requête. Zéro signifie ignorer la requête. Pour en savoir plus, consultez la surallocation de mémoire.

​

memory_overcommit_ratio_denominator_for_user

Il représente la limite de mémoire souple lorsque la limite stricte est atteinte au niveau de l’utilisateur. Cette valeur est utilisée pour calculer le ratio de surallocation pour la requête. Zéro signifie que la requête est ignorée. Pour en savoir plus, consultez la surallocation de mémoire.

​

memory_profiler_sample_max_allocation_size

Collecte des allocations aléatoires d’une taille inférieure ou égale à la valeur spécifiée, avec une probabilité égale à memory_profiler_sample_probability. 0 signifie que le paramètre est désactivé. Vous pouvez définir max_untracked_memory sur 0 pour que ce seuil fonctionne comme prévu.

​

memory_profiler_sample_min_allocation_size

Collecte les allocations aléatoires d’une taille supérieure ou égale à la valeur spécifiée, avec une probabilité égale à memory_profiler_sample_probability. 0 signifie que le paramètre est désactivé. Vous pouvez définir ‘max_untracked_memory’ sur 0 afin que ce seuil fonctionne comme prévu.

​

memory_profiler_sample_probability

Collecte des allocations et désallocations aléatoires et les écrit dans system.trace_log avec le trace_type ‘MemorySample’. La probabilité s’applique à chaque alloc/free, quelle que soit la taille de l’allocation (elle peut être modifiée avec memory_profiler_sample_min_allocation_size et memory_profiler_sample_max_allocation_size). Notez que l’échantillonnage n’a lieu que lorsque la quantité de mémoire non suivie dépasse ‘max_untracked_memory’. Vous pouvez définir ‘max_untracked_memory’ sur 0 pour obtenir un échantillonnage encore plus fin.

​

memory_profiler_step

Définit le pas du profileur mémoire. Chaque fois que l’utilisation mémoire de la requête dépasse le palier suivant, exprimé en nombre d’octets, le profileur mémoire collecte la stacktrace d’allocation et l’écrit dans trace_log.

Valeurs possibles :

• Un nombre entier positif d’octets.

• 0 pour désactiver le profileur mémoire.

​

memory_tracker_fault_probability

Pour tester exception safety, lever une exception chaque fois que vous allouez de la mémoire, selon la probabilité spécifiée.

​

memory_usage_overcommit_max_wait_microseconds

Temps maximal pendant lequel un thread attend que de la mémoire soit libérée en cas de surallocation mémoire au niveau utilisateur. Si le délai d’attente est atteint et que la mémoire n’est pas libérée, une exception est levée. Pour en savoir plus sur la surallocation mémoire.

​

merge_table_max_tables_to_look_for_schema_inference

Lors de la création d’une table Merge sans schéma explicite, ou lors de l’utilisation de la fonction de table merge, le schéma est déduit comme l’union d’au plus le nombre spécifié de tables correspondantes. Si le nombre de tables est supérieur, le schéma sera déduit à partir des premières tables, dans la limite du nombre spécifié.

​

merge_tree_coarse_index_granularity

Lors de la recherche de données, ClickHouse vérifie les marques de données dans le fichier d’index. Si ClickHouse constate que les clés recherchées se trouvent dans une plage donnée, il divise cette plage en merge_tree_coarse_index_granularity sous-plages et y recherche récursivement les clés recherchées.

Valeurs possibles :

• Tout entier pair positif.

​

merge_tree_compact_parts_min_granules_to_multibuffer_read

N’a d’effet que dans ClickHouse Cloud. Nombre de granules dans une stripe d’une part compacte de tables MergeTree à partir duquel le lecteur multitampon est utilisé, ce qui permet la lecture parallèle et la prélecture. En cas de lecture depuis un système de fichiers distant, l’utilisation du lecteur multitampon augmente le nombre de requêtes de lecture.

​

merge_tree_determine_task_size_by_prewhere_columns

Indique s’il faut utiliser uniquement la taille des colonnes prewhere pour déterminer la taille de la tâche de lecture.

​

merge_tree_max_bytes_to_use_cache

Si ClickHouse doit lire plus de merge_tree_max_bytes_to_use_cache octets au cours d’une requête, il n’utilise pas le cache des blocs non compressés.

Le cache des blocs non compressés stocke les données extraites pour les requêtes. ClickHouse utilise ce cache pour accélérer les réponses aux petites requêtes répétées. Ce paramètre évite que le cache soit pollué par des requêtes qui lisent un grand volume de données. Le paramètre serveur uncompressed_cache_size définit la taille du cache des blocs non compressés.

Valeurs possibles :

• Tout entier positif.

​

merge_tree_max_rows_to_use_cache

Si ClickHouse doit lire plus de merge_tree_max_rows_to_use_cache lignes dans une seule requête, il n’utilise pas le cache des blocs non compressés.

Le cache des blocs non compressés stocke les données extraites pour les requêtes. ClickHouse utilise ce cache pour accélérer les réponses aux petites requêtes répétées. Ce paramètre évite que le cache soit perturbé par des requêtes qui lisent un grand volume de données. Le paramètre de serveur uncompressed_cache_size définit la taille du cache des blocs non compressés.

Valeurs possibles :

• Tout entier positif.

​

merge_tree_min_bytes_for_concurrent_read

Si le nombre d’octets à lire à partir d’un fichier d’une table utilisant le moteur MergeTree dépasse merge_tree_min_bytes_for_concurrent_read, ClickHouse tente alors de lire ce fichier de manière concurrente à l’aide de plusieurs threads.

Valeur possible :

• Entier positif.

​

merge_tree_min_bytes_for_concurrent_read_for_remote_filesystem

Le nombre minimal d’octets à lire dans un fichier avant que le moteur MergeTree puisse paralléliser la lecture lors d’une lecture depuis un système de fichiers distant. Nous ne recommandons pas d’utiliser ce paramètre.

Valeurs possibles :

• Entier positif.

​

merge_tree_min_bytes_for_seek

Si la distance entre deux blocs de données à lire dans un fichier est inférieure à merge_tree_min_bytes_for_seek octets, ClickHouse lit alors séquentiellement une plage du fichier contenant les deux blocs, évitant ainsi une opération de seek supplémentaire.

Valeurs possibles :

• Tout entier positif.

​

merge_tree_min_bytes_per_task_for_remote_reading

Alias : filesystem_prefetch_min_bytes_for_single_read_task

Nombre minimal d’octets à lire par tâche.

​

merge_tree_min_read_task_size

Limite inférieure absolue de la taille des tâches (même lorsque le nombre de granules est faible et que le nombre de threads disponibles est élevé, nous n’allouerons pas de tâches plus petites

​

merge_tree_min_rows_for_concurrent_read

Si le nombre de lignes à lire dans un fichier d’une table MergeTree dépasse merge_tree_min_rows_for_concurrent_read, ClickHouse tente alors d’effectuer une lecture concurrente de ce fichier sur plusieurs threads.

Valeurs possibles :

• Entier positif.

​

merge_tree_min_rows_for_concurrent_read_for_remote_filesystem

Nombre minimal de lignes à lire dans un fichier avant que le moteur MergeTree puisse paralléliser la lecture lors d’une lecture depuis un système de fichiers distant. Nous déconseillons d’utiliser ce paramètre.

Valeurs possibles :

• Entier positif.

​

merge_tree_min_rows_for_seek

Si l’écart entre deux blocs de données à lire dans un même fichier est inférieur à merge_tree_min_rows_for_seek lignes, ClickHouse n’effectue pas de seek dans le fichier, mais lit les données de manière séquentielle.

Valeurs possibles :

• Tout entier positif.

​

merge_tree_read_split_ranges_into_intersecting_and_non_intersecting_injection_probability

Pour tester PartsSplitter : scinde les plages de lecture en plages qui se chevauchent et en plages qui ne se chevauchent pas à chaque lecture depuis MergeTree, selon la probabilité spécifiée.

​

merge_tree_storage_snapshot_sleep_ms

Introduit un délai artificiel (en millisecondes) lors de la création d’un instantané de stockage pour les tables MergeTree. À utiliser uniquement à des fins de test et de débogage.

Valeurs possibles :

• 0 - Aucun délai (par défaut)
• N - Délai en millisecondes

​

merge_tree_use_const_size_tasks_for_remote_reading

Indique s’il faut utiliser des tâches de taille constante pour la lecture depuis une table distante.

​

merge_tree_use_deserialization_prefixes_cache

Active la mise en cache des métadonnées de colonnes à partir des préfixes de fichier lors de la lecture depuis des disques distants dans MergeTree.

​

merge_tree_use_prefixes_deserialization_thread_pool

Active l’utilisation du pool de threads pour la lecture parallèle des préfixes dans les wide parts de MergeTree. La taille de ce pool de threads est contrôlée par le paramètre serveur max_prefixes_deserialization_thread_pool_size.

​

merge_tree_use_v1_object_and_dynamic_serialization

Lorsqu’il est activé, la version de sérialisation V1 des types JSON et Dynamic sera utilisée dans MergeTree à la place de V2. La modification de ce paramètre ne prend effet qu’après le redémarrage du serveur.

​

metrics_perf_events_enabled

Si cette option est activée, certains événements perf seront mesurés tout au long de l’exécution des requêtes.

​

metrics_perf_events_list

Liste de métriques perf séparées par des virgules, qui seront mesurées pendant l’exécution des requêtes. Si vide, tous les événements sont pris en compte. Voir PerfEventInfo dans les sources pour la liste des événements disponibles.

​

min_bytes_to_use_direct_io

Le volume minimal de données nécessaire pour utiliser l’accès direct au disque de stockage en E/S.

ClickHouse utilise ce paramètre lors de la lecture des données depuis des tables. Si le volume total sur le disque de toutes les données à lire dépasse min_bytes_to_use_direct_io octets, ClickHouse lit alors les données depuis le disque de stockage avec l’option O_DIRECT.

Valeurs possibles :

• 0 — Les E/S directes sont désactivées.
• Entier positif.

​

min_bytes_to_use_mmap_io

Il s’agit d’un paramètre expérimental. Il définit le volume minimal de mémoire à partir duquel les gros fichiers sont lus sans copier les données du noyau vers l’espace utilisateur. Le seuil recommandé est d’environ 64 Mo, car mmap/munmap est lent. Ce paramètre n’est utile que pour les gros fichiers et n’apporte un bénéfice que si les données résident dans le cache de pages.

Valeurs possibles :

• Entier positif.
• 0 — Les gros fichiers sont lus uniquement en copiant les données du noyau vers l’espace utilisateur.

​

min_chunk_bytes_for_parallel_parsing

• Type : entier non signé
• Valeur par défaut : 1 MiB

Taille minimale, en octets, du fragment que chaque thread analysera en parallèle.

​

min_compress_block_size

Pour les tables MergeTree. Afin de réduire la latence du traitement des requêtes, un bloc est compressé lors de l’écriture du repère suivant si sa taille est au moins égale à min_compress_block_size. Par défaut, 65 536.

La taille réelle du bloc, si les données non compressées sont inférieures à max_compress_block_size, n’est inférieure ni à cette valeur, ni au volume de données correspondant à un repère.

Prenons un exemple. Supposons que index_granularity ait été défini sur 8192 lors de la création de la table.

Nous écrivons une colonne de type UInt32 (4 octets par valeur). Lors de l’écriture de 8192 lignes, cela représente un total de 32 Ko de données. Comme min_compress_block_size = 65 536, un bloc compressé sera formé tous les deux repères.

Nous écrivons une colonne URL de type String (taille moyenne de 60 octets par valeur). Lors de l’écriture de 8192 lignes, cela représente en moyenne un peu moins de 500 Ko de données. Comme cette valeur dépasse 65 536, un bloc compressé sera formé pour chaque repère. Dans ce cas, lors de la lecture des données sur le disque dans la plage d’un seul repère, aucune donnée supplémentaire ne devra être décompressée.

Il s’agit d’un paramètre destiné aux utilisateurs expérimentés, et vous ne devriez pas le modifier si vous débutez avec ClickHouse.

​

min_count_to_compile_aggregate_expression

Nombre minimal d’expressions d’agrégation identiques à partir duquel la compilation JIT commence. Fonctionne uniquement si le paramètre compile_aggregate_expressions est activé.

Valeurs possibles :

• Entier positif.
• 0 — Les expressions d’agrégation identiques sont toujours compilées en JIT.

​

min_count_to_compile_expression

Nombre minimal d’exécutions d’une même expression avant qu’elle soit compilée.

​

min_count_to_compile_sort_description

Le nombre de descriptions de tri identiques avant leur compilation en JIT

​

min_execution_speed

Vitesse d’exécution minimale en lignes par seconde. Vérifiée pour chaque bloc de données lorsque timeout_before_checking_execution_speed expire. Si la vitesse d’exécution est inférieure, une exception est levée.

​

min_execution_speed_bytes

Le nombre minimal d’octets exécutés par seconde. Vérifié pour chaque bloc de données lorsque timeout_before_checking_execution_speed expire. Si la vitesse d’exécution est inférieure, une exception est levée.

​

min_external_table_block_size_bytes

Fusionne les blocs transmis à la table externe pour atteindre la taille spécifiée en octets, s’ils ne sont pas assez volumineux.

​

min_external_table_block_size_rows

Regroupe les blocs transmis à la table externe afin d’atteindre le nombre de lignes spécifié, si les blocs ne sont pas assez volumineux.

​

min_filtered_ratio_for_lazy_final

Ratio minimal de marks filtrées par l’analyse des index pour l’optimisation lazy FINAL. Si une fraction inférieure à ce seuil de marks est filtrée, le système revient au mode FINAL normal. La valeur 0 désactive cette vérification.

​

min_free_disk_bytes_to_perform_insert

Nombre minimal d’octets d’espace disque libre requis pour effectuer une insertion.

​

min_free_disk_ratio_to_perform_insert

Ratio minimal d’espace disque libre requis pour effectuer une insertion.

​

min_free_disk_space_for_temporary_data

Espace disque minimal à conserver lors de l’écriture de données temporaires utilisées pour le tri externe et l’agrégation.

​

min_hit_rate_to_use_consecutive_keys_optimization

Taux de succès minimal d’un cache utilisé pour l’optimisation des clés consécutives dans l’agrégation, afin de la maintenir activée

​

min_insert_block_size_bytes

Taille minimale des blocs (en octets) à former pour l’insertion dans une table.

Ce paramètre fonctionne avec min_insert_block_size_rows et contrôle la formation des blocs dans les mêmes contextes (analyse du format et opérations INSERT). Consultez min_insert_block_size_rows pour plus de détails sur le moment et la manière dont ces paramètres sont appliqués.

Valeurs possibles :

• Entier positif.
• 0 — le paramètre n’intervient pas dans la formation des blocs.

​

min_insert_block_size_bytes_for_materialized_views

Définit le nombre minimal d’octets qu’un bloc doit contenir pour pouvoir être inséré dans une table par une requête INSERT. Les blocs plus petits sont regroupés en blocs plus grands. Ce paramètre s’applique uniquement aux blocs insérés dans une vue matérialisée. En ajustant ce paramètre, vous contrôlez le regroupement des blocs lors de l’envoi vers la vue matérialisée et évitez une utilisation excessive de la mémoire.

Valeurs possibles :

• Tout entier positif.
• 0 — Regroupement désactivé.

Voir aussi

• min_insert_block_size_bytes

​

min_insert_block_size_rows

La taille minimale des blocs (en lignes) à former pour l’insertion dans une table.

Ce paramètre contrôle la formation des blocs dans deux contextes :

1. Analyse des formats d’entrée : lorsque le serveur analyse des formats d’entrée orientés lignes (CSV, TSV, JSONEachRow, etc.) depuis n’importe quelle interface (HTTP, clickhouse-client avec des données intégrées, gRPC, PostgreSQL wire protocol), les blocs sont émis lorsque :

   • Les deux seuils min_insert_block_size_rows AND min_insert_block_size_bytes sont atteints, OR
   • L’un des deux seuils max_insert_block_size_rows OR max_insert_block_size_bytes est atteint

   Remarque : lorsque vous utilisez clickhouse-client ou clickhouse-local pour lire depuis un fichier, c’est le client lui-même qui analyse les données, et ce paramètre s’applique côté client.

2. Opérations INSERT : pendant les requêtes INSERT et lorsque les données transitent par des vues matérialisées, le comportement de ce paramètre dépend de use_strict_insert_block_limits :

   • Lorsqu’il est activé : les blocs sont émis lorsque :

     • Seuils min (AND) : les deux seuils min_insert_block_size_rows AND min_insert_block_size_bytes sont atteints
     • Seuils max (OR) : l’un des deux seuils max_insert_block_size_rows OR max_insert_block_size_bytes est atteint

   • Lorsqu’il est désactivé (par défaut) : les blocs sont émis lorsque min_insert_block_size_rows OR min_insert_block_size_bytes est atteint. Les paramètres max_insert_block_size ne sont pas pris en compte.

Valeurs possibles :

• Entier positif.
• 0 — le paramètre ne participe pas à la formation des blocs.

​

min_insert_block_size_rows_for_materialized_views

Définit le nombre minimal de lignes qu’un bloc doit contenir pour pouvoir être inséré dans une table par une requête INSERT. Les blocs plus petits sont fusionnés en blocs plus grands. Ce paramètre s’applique uniquement aux blocs insérés dans une vue matérialisée. En ajustant ce paramètre, vous contrôlez la fusion des blocs lors de l’alimentation d’une vue matérialisée et évitez une utilisation excessive de la mémoire.

Valeurs possibles :

• Tout entier positif.
• 0 — Fusion désactivée.

Voir aussi

• min_insert_block_size_rows

​

min_joined_block_size_bytes

Taille minimale du bloc, en octets, pour les blocs d’entrée et de sortie de JOIN (si l’algorithme JOIN le prend en charge). Les petits blocs seront regroupés. 0 signifie sans limite.

​

min_joined_block_size_rows

Nombre minimal de lignes par bloc pour les blocs d’entrée et de sortie de JOIN (si l’algorithme de jointure le prend en charge). Les petits blocs seront regroupés. 0 signifie sans limite.

​

min_os_cpu_wait_time_ratio_to_throw

Rapport minimal entre les temps d’attente du CPU au niveau du système d’exploitation (métrique OSCPUWaitMicroseconds) et les temps d’activité (métrique OSCPUVirtualTimeMicroseconds) à partir duquel le rejet de requêtes peut être envisagé. Une interpolation linéaire entre le rapport minimal et le rapport maximal est utilisée pour calculer la probabilité ; à ce seuil, cette probabilité est nulle.

​

min_outstreams_per_resize_after_split

Spécifie le nombre minimal de flux de sortie d’un processeur Resize ou StrictResize après l’exécution d’un fractionnement lors de la génération du pipeline. Si le nombre de flux résultant est inférieur à cette valeur, l’opération de fractionnement n’a pas lieu.

​

Qu’est-ce qu’un nœud Resize

Un nœud Resize est un processeur du pipeline de requête qui ajuste le nombre de flux de données qui y circulent. Il peut augmenter ou diminuer le nombre de flux afin d’équilibrer la charge de travail entre plusieurs threads ou processeurs. Par exemple, si une requête nécessite davantage de parallélisme, le nœud Resize peut scinder un flux unique en plusieurs flux. À l’inverse, il peut fusionner plusieurs flux pour en réduire le nombre et regrouper le traitement des données.

Le nœud Resize garantit une répartition uniforme des données entre les flux, tout en préservant la structure des blocs de données. Cela permet d’optimiser l’utilisation des ressources et d’améliorer les performances des requêtes.

​

Pourquoi le nœud Resize doit être fractionné

Pendant l’exécution du pipeline, le status_mutex de ExecutingGraph::Node du nœud Resize, qui sert de point central, est fortement sujet à la contention, en particulier dans les environnements comportant un grand nombre de cœurs, ce qui entraîne :

1. Une latence accrue pour ExecutingGraph::updateNode, ce qui affecte directement les performances des requêtes.
2. Un gaspillage excessif de cycles CPU dans la contention sur le spin-lock (native_queued_spin_lock_slowpath), ce qui dégrade l’efficacité.
3. Une utilisation réduite du CPU, ce qui limite le parallélisme et le débit.

​

Comment le nœud Resize est fractionné

1. Le nombre de flux de sortie est vérifié afin de s’assurer que le fractionnement peut être effectué : les flux de sortie de chaque processeur issu du fractionnement atteignent ou dépassent le seuil min_outstreams_per_resize_after_split.
2. Le nœud Resize est divisé en nœuds Resize plus petits, avec un nombre égal de ports, chacun gérant un sous-ensemble des flux d’entrée et de sortie.
3. Chaque groupe est traité indépendamment, ce qui réduit la contention sur les verrous.

​

Fractionnement d’un nœud Resize avec des entrées/sorties arbitraires

Dans certains cas, lorsque le nombre d’entrées/sorties n’est pas divisible par le nombre de nœuds Resize après fractionnement, certaines entrées sont reliées à des NullSource et certaines sorties à des NullSink. Cela permet d’effectuer le fractionnement sans affecter le flux global de données.

​

Objectif du paramètre

Le paramètre min_outstreams_per_resize_after_split garantit que le fractionnement des nœuds Resize a du sens et évite de créer trop peu de flux, ce qui pourrait nuire à l’efficacité du traitement parallèle. En imposant un nombre minimal de flux de sortie, ce paramètre aide à maintenir un équilibre entre le parallélisme et le surcoût, afin d’optimiser l’exécution des requêtes dans les scénarios impliquant le fractionnement et la fusion de flux.

​

Désactivation du paramètre

Pour désactiver le fractionnement des nœuds Resize, définissez ce paramètre sur 0. Cela empêchera le fractionnement des nœuds Resize lors de la génération du pipeline, ce qui leur permettra de conserver leur structure d’origine sans être fractionnés en nœuds plus petits.

​

min_table_rows_to_use_projection_index

Si le nombre estimé de lignes à lire dans la table est supérieur ou égal à ce seuil, ClickHouse essaiera d’utiliser l’index de projection lors de l’exécution de la requête.

​

mongodb_throw_on_unsupported_query

Si ce paramètre est activé, les tables MongoDB renverront une erreur lorsqu’une requête MongoDB ne peut pas être générée. Sinon, ClickHouse lit l’intégralité de la table et la traite localement. Cette option ne s’applique pas lorsque ‘allow_experimental_analyzer=0’.

​

move_all_conditions_to_prewhere

Déplacer toutes les conditions pouvant l’être de WHERE vers PREWHERE

​

move_primary_key_columns_to_end_of_prewhere

Déplace les conditions PREWHERE contenant des colonnes de clé primaire à la fin de la chaîne d’opérations AND. Il est probable que ces conditions soient déjà prises en compte lors de l’analyse de la clé primaire et qu’elles n’apportent donc pas grand-chose au filtrage PREWHERE.

​

multiple_joins_try_to_keep_original_names

Ne pas ajouter d’alias à la liste d’expressions de premier niveau lors de la réécriture de jointures multiples

​

mutations_execute_nondeterministic_on_initiator

Si la valeur est true, les fonctions constantes non déterministes (par ex. la fonction now()) sont exécutées sur le nœud initiateur puis remplacées par des littéraux dans les requêtes UPDATE et DELETE. Cela permet de maintenir la synchronisation des données entre les répliques lors de l’exécution de mutations avec des fonctions constantes non déterministes. Valeur par défaut : false.

​

mutations_execute_subqueries_on_initiator

Si true, les sous-requêtes scalaires sont exécutées sur l’initiateur, puis remplacées par des littéraux dans les requêtes UPDATE et DELETE. Valeur par défaut : false.

​

mutations_max_literal_size_to_replace

La taille maximale, en octets, du littéral sérialisé à remplacer dans les requêtes UPDATE et DELETE. Ne prend effet que si au moins l’un des deux paramètres ci-dessus est activé. Valeur par défaut : 16384 (16 KiB).

​

mutations_sync

Permet d’exécuter de manière synchrone les requêtes ALTER TABLE ... UPDATE|DELETE|MATERIALIZE INDEX|MATERIALIZE PROJECTION|MATERIALIZE COLUMN|MATERIALIZE STATISTICS (mutations).

Valeurs possibles :

Valeur	Description
0	Les mutations s’exécutent de manière asynchrone.
1	La requête attend que toutes les mutations se terminent sur le serveur actuel.
2	La requête attend que toutes les mutations se terminent sur toutes les répliques (si elles existent).
3	La requête attend uniquement les répliques actives. Pris en charge uniquement pour SharedMergeTree. Pour ReplicatedMergeTree, le comportement est identique à mutations_sync = 2.

​

mysql_datatypes_support_level

Définit comment les types MySQL sont convertis en types ClickHouse correspondants. Liste de valeurs séparées par des virgules, dans n’importe quelle combinaison de decimal, datetime64, date2Date32 ou date2String. Toutes les correspondances modernes (decimal, datetime64, date2Date32) sont activées par défaut.

• decimal : convertit les types NUMERIC et DECIMAL en Decimal lorsque la précision le permet.
• datetime64 : convertit les types DATETIME et TIMESTAMP en DateTime64 au lieu de DateTime lorsque la précision n’est pas 0.
• date2Date32 : convertit DATE en Date32 au lieu de Date. Prend le pas sur date2String.
• date2String : convertit DATE en String au lieu de Date. Est surchargé par datetime64.

​

mysql_map_fixed_string_to_text_in_show_columns

Lorsque ce paramètre est activé, le type de données ClickHouse FixedString est affiché en TEXT dans SHOW COLUMNS.

N’a d’effet que lorsque la connexion est établie via le MySQL wire protocol.

• 0 - Utiliser BLOB.
• 1 - Utiliser TEXT.

​

mysql_map_string_to_text_in_show_columns

Lorsqu’il est activé, le type de données ClickHouse String est affiché sous la forme TEXT dans SHOW COLUMNS.

N’a d’effet que lorsque la connexion est établie via le MySQL wire protocol.

• 0 - Utiliser BLOB.
• 1 - Utiliser TEXT.

​

mysql_max_rows_to_insert

Nombre maximal de lignes lors d’une insertion MySQL par lot avec le moteur de stockage MySQL

​

network_compression_method

Le codec utilisé pour la compression des communications client/serveur et serveur/serveur.

Valeurs possibles :

• NONE — aucune compression.
• LZ4 — utilise le codec LZ4.
• LZ4HC — utilise le codec LZ4HC.
• ZSTD — utilise le codec ZSTD.

Voir aussi

• network_zstd_compression_level

​

network_zstd_compression_level

Définit le niveau de compression ZSTD. Utilisé uniquement lorsque network_compression_method est défini sur ZSTD.

Valeurs possibles :

• Entier positif compris entre 1 et 15.

​

normalize_function_names

Normaliser les noms de fonction en leurs noms canoniques

​

number_of_mutations_to_delay

Si la table contient au moins ce nombre de mutations non terminées, ralentissez artificiellement les mutations de la table. 0 - désactivé

​

number_of_mutations_to_throw

Si la table mutée contient au moins ce nombre de mutations non terminées, déclencher l’exception ‘Too many mutations …’. 0 - désactivé

​

odbc_bridge_connection_pool_size

Taille du pool de connexions pour chaque chaîne de paramètres de connexion de l’ODBC bridge.

​

odbc_bridge_use_connection_pooling

Active le pool de connexions dans ODBC bridge. Si cette option est définie sur false, une nouvelle connexion est créée à chaque fois.

​

offset

Définit le nombre de lignes à ignorer avant de commencer à renvoyer les lignes de la requête. Ce paramètre ajuste le décalage défini par la clause OFFSET, de sorte que ces deux valeurs s’additionnent.

Valeurs possibles :

• 0 — Aucune ligne n’est ignorée.
• Entier positif.

Exemple

Table d’entrée :

CREATE TABLE test (i UInt64) ENGINE = MergeTree() ORDER BY i;
INSERT INTO test SELECT number FROM numbers(500);

Requête :

SET limit = 5;
SET offset = 7;
SELECT * FROM test LIMIT 10 OFFSET 100;

Résultat :

┌───i─┐
│ 107 │
│ 108 │
│ 109 │
└─────┘

​

opentelemetry_start_keeper_trace_probability

Probabilité d’initier une trace pour une requête ZooKeeper, qu’une trace parente existe ou non.

Valeurs possibles :

• ‘auto’ - Équivaut au paramètre opentelemetry_start_trace_probability
• 0 — Le traçage est désactivé
• 0 à 1 — Probabilité (par ex. : 1.0 = toujours activé)

​

opentelemetry_start_trace_probability

Définit la probabilité que ClickHouse démarre une trace pour les requêtes exécutées (si aucun contexte de trace parent n’est fourni).

Valeurs possibles :

• 0 — La trace est désactivée pour toutes les requêtes exécutées (si aucun contexte de trace parent n’est fourni).
• Nombre à virgule flottante positif dans l’intervalle [0..1]. Par exemple, si la valeur du paramètre est 0,5, ClickHouse peut démarrer une trace en moyenne pour la moitié des requêtes.
• 1 — La trace est activée pour toutes les requêtes exécutées.

​

opentelemetry_trace_cpu_scheduling

Collecte les spans OpenTelemetry pour l’ordonnancement préemptif du CPU des workloads.

​

opentelemetry_trace_processors

Collecte les spans OpenTelemetry pour les processeurs.

​

optimize_aggregation_in_order

Active l’optimisation de GROUP BY dans les requêtes SELECT afin d’agréger les données selon l’ordre correspondant dans les tables MergeTree.

Valeurs possibles :

• 0 — l’optimisation de GROUP BY est désactivée.
• 1 — l’optimisation de GROUP BY est activée.

Voir aussi

• Optimisation de GROUP BY

​

optimize_aggregators_of_group_by_keys

Élimine les agrégateurs min/max/any/anyLast des clés GROUP BY dans la section SELECT

​

optimize_and_compare_chain

Propage les comparaisons avec des constantes dans les chaînes AND afin d’améliorer les capacités de filtrage. Prend en charge les opérateurs <, <=, >, >=, = ainsi que leurs combinaisons. Par exemple, (a < b) AND (b < c) AND (c < 5) deviendrait (a < b) AND (b < c) AND (c < 5) AND (b < 5) AND (a < 5).

​

optimize_append_index

Utilisez les contraintes pour ajouter une condition d’index. La valeur par défaut est false.

Valeurs possibles :

• true, false

​

optimize_arithmetic_operations_in_aggregate_functions

Déplace les opérations arithmétiques en dehors des fonctions d’agrégation

​

optimize_const_name_size

Remplacer par une valeur scalaire et utiliser un hash comme nom pour les grandes constantes (la taille est estimée en fonction de la longueur du nom).

Valeurs possibles :

• entier positif - longueur maximale du nom,
• 0 — toujours,
• entier négatif - jamais.

​

optimize_count_from_files

Active ou désactive l’optimisation du comptage du nombre de lignes dans des fichiers de différents formats d’entrée. Elle s’applique aux fonctions de table/moteurs file/s3/url/hdfs/azureBlobStorage.

Valeurs possibles :

• 0 — Optimisation désactivée.
• 1 — Optimisation activée.

​

optimize_dictget_tuple_element

Réécrit tupleElement(dictGet('dict', ('a', 'b', 'c'), key), 2) en dictGet('dict', 'b', key) afin d’éviter de récupérer des attributs de dictionnaire inutiles. Prend en charge l’accès positionnel (.1, .2, …) et l’accès nommé (.b), et s’applique également à dictGetOrDefault lorsque l’argument par défaut est un tuple constant ou un tuple(...) de constantes.

​

optimize_distinct_in_order

Active l’optimisation de DISTINCT si certaines colonnes de DISTINCT constituent un préfixe de tri. Par exemple, un préfixe de la clé de tri dans MergeTree ou de l’instruction ORDER BY

​

optimize_distributed_group_by_sharding_key

Optimise les requêtes GROUP BY sharding_key en évitant une agrégation coûteuse sur le serveur initiateur (ce qui réduira la consommation mémoire de la requête sur ce serveur).

Les types de requêtes suivants sont pris en charge (ainsi que toutes leurs combinaisons) :

• SELECT DISTINCT [..., ]sharding_key[, ...] FROM dist
• SELECT ... FROM dist GROUP BY sharding_key[, ...]
• SELECT ... FROM dist GROUP BY sharding_key[, ...] ORDER BY x
• SELECT ... FROM dist GROUP BY sharding_key[, ...] LIMIT 1
• SELECT ... FROM dist GROUP BY sharding_key[, ...] LIMIT 1 BY x

Les types de requêtes suivants ne sont pas pris en charge (la prise en charge de certains pourra être ajoutée ultérieurement) :

• SELECT ... GROUP BY sharding_key[, ...] WITH TOTALS
• SELECT ... GROUP BY sharding_key[, ...] WITH ROLLUP
• SELECT ... GROUP BY sharding_key[, ...] WITH CUBE
• SELECT ... GROUP BY sharding_key[, ...] SETTINGS extremes=1

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Voir aussi :

• distributed_group_by_no_merge
• distributed_push_down_limit
• optimize_skip_unused_shards

À l’heure actuelle, ce réglage nécessite optimize_skip_unused_shards (la raison est qu’il pourrait un jour être activé par défaut et ne fonctionner correctement que si les données ont été insérées via une table Distributed, c’est-à-dire si elles sont distribuées selon sharding_key).

​

optimize_dry_run_check_part

Lorsqu’il est activé, OPTIMIZE ... DRY RUN valide la part fusionnée obtenue à l’aide de checkDataPart. Si la vérification échoue, une exception est levée.

​

optimize_empty_string_comparisons

Convertit les expressions telles que col = ” ou ” = col en empty(col), et col != ” ou ” != col en notEmpty(col), uniquement lorsque col est de type String ou FixedString.

​

optimize_extract_common_expressions

Autorise l’extraction des expressions communes des disjonctions dans les expressions WHERE, PREWHERE, ON, HAVING et QUALIFY. Une expression logique comme (A AND B) OR (A AND C) peut être réécrite en A AND (B OR C), ce qui peut aider à exploiter :

• les index dans des expressions de filtrage simples
• l’optimisation de CROSS JOIN en INNER JOIN

​

optimize_functions_to_subcolumns

Active ou désactive l’optimisation qui consiste à réécrire certaines fonctions pour lire des sous-colonnes. Cela réduit la quantité de données à lire.

Ces fonctions peuvent être réécrites :

• length pour lire la sous-colonne size0.
• empty pour lire la sous-colonne size0.
• notEmpty pour lire la sous-colonne size0.
• isNull pour lire la sous-colonne null.
• isNotNull pour lire la sous-colonne null.
• count pour lire la sous-colonne null.
• mapKeys pour lire la sous-colonne keys.
• mapValues pour lire la sous-colonne values.

Valeurs possibles :

• 0 — Optimisation désactivée.
• 1 — Optimisation activée.

​

optimize_group_by_constant_keys

Optimiser GROUP BY lorsque toutes les clés du bloc sont constantes

​

optimize_group_by_function_keys

Élimine les fonctions appliquées aux autres clés dans la clause GROUP BY

​

optimize_if_chain_to_multiif

Remplace les enchaînements if(cond1, then1, if(cond2, ...)) par multiIf. Actuellement, cela n’est pas avantageux pour les types numériques.

​

optimize_if_transform_strings_to_enum

Remplace les arguments de type String dans If et Transform par des enum. Désactivé par défaut, car cela pourrait entraîner une modification incohérente dans une requête distribuée, ce qui provoquerait son échec.

​

optimize_injective_functions_in_group_by

Remplace les fonctions injectives par leurs arguments dans la clause GROUP BY

​

optimize_injective_functions_in_limit_by

Remplace les fonctions injectives par leurs arguments dans la clause LIMIT BY.

Exemple : LIMIT 5 BY toString(x) devient LIMIT 5 BY x.

​

optimize_injective_functions_inside_uniq

Supprime les fonctions injectives à un seul argument à l’intérieur des fonctions uniq*().

​

optimize_inverse_dictionary_lookup

Évite les recherches inverses répétées dans le dictionnaire en effectuant des recherches plus rapides dans un ensemble précalculé de valeurs de clé possibles.

​

optimize_limit_by_function_keys

Supprime, dans la clause LIMIT BY, les clés qui sont des fonctions d’autres clés.

Exemple : LIMIT 5 BY x, f(x) devient LIMIT 5 BY x.

​

optimize_limit_by_in_order

Optimise les requêtes SELECT ... LIMIT N BY <cols> lorsque <cols> (dans n’importe quel ordre) constituent un préfixe de la clé de tri de la table, ou le deviennent après que WHERE col = const a fixé les premières colonnes. Lorsque ce paramètre est activé, la source lit les données dans l’ordre de la clé primaire, de sorte que les lignes ayant les mêmes valeurs pour les colonnes BY arrivent de façon contiguë dans chaque flux. Lorsque les données arrivent dans un seul flux trié, LIMIT BY les filtre en mode streaming avec une mémoire O(1), au lieu de construire une table de hachage pour chaque combinaison distincte de colonnes BY rencontrée. Lorsque les données triées arrivent dans plusieurs flux et que les mêmes valeurs BY peuvent apparaître dans plusieurs d’entre eux, chaque flux est d’abord préfiltré en mode streaming jusqu’à un maximum de LIMIT + OFFSET lignes par groupe, puis les flux sont combinés et un LIMIT BY final, basé sur une table de hachage, déduplique les groupes qui s’étendent sur plusieurs flux. Cette passe finale conserve malgré tout une entrée pour chaque combinaison distincte de colonnes BY, mais elle ne traite que les lignes préfiltrées.

​

optimize_min_equality_disjunction_chain_length

Longueur minimale de l’expression expr = x1 OR ... expr = xN pour l’optimisation

​

optimize_min_inequality_conjunction_chain_length

Longueur minimale de l’expression expr <> x1 AND ... expr <> xN pour l’optimisatio

​

optimize_move_to_prewhere

Active ou désactive l’optimisation automatique de PREWHERE pour les requêtes SELECT.

Fonctionne uniquement avec les tables *MergeTree.

Valeurs possibles :

• 0 — L’optimisation automatique de PREWHERE est désactivée.
• 1 — L’optimisation automatique de PREWHERE est activée.

​

optimize_move_to_prewhere_if_final

Active ou désactive l’optimisation automatique de PREWHERE dans les requêtes SELECT avec le modificateur FINAL.

Fonctionne uniquement pour les tables *MergeTree.

Valeurs possibles :

• 0 — L’optimisation automatique de PREWHERE dans les requêtes SELECT avec le modificateur FINAL est désactivée.
• 1 — L’optimisation automatique de PREWHERE dans les requêtes SELECT avec le modificateur FINAL est activée.

Voir aussi

• paramètre optimize_move_to_prewhere

​

optimize_multiif_to_if

Remplace « multiIf » par « if » lorsqu’il n’y a qu’une seule condition.

​

optimize_normalize_count_variants

Réécrire les fonctions d’agrégation équivalentes à count() sur le plan sémantique en count().

​

optimize_on_insert

Active ou désactive la transformation des données avant l’insertion, comme si une fusion avait été effectuée sur ce bloc (selon le moteur de table).

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Exemple

Différence entre activé et désactivé :

Requête :

SET optimize_on_insert = 1;

CREATE TABLE test1 (`FirstTable` UInt32) ENGINE = ReplacingMergeTree ORDER BY FirstTable;

INSERT INTO test1 SELECT number % 2 FROM numbers(5);

SELECT * FROM test1;

SET optimize_on_insert = 0;

CREATE TABLE test2 (`SecondTable` UInt32) ENGINE = ReplacingMergeTree ORDER BY SecondTable;

INSERT INTO test2 SELECT number % 2 FROM numbers(5);

SELECT * FROM test2;

Résultat :

┌─FirstTable─┐
│          0 │
│          1 │
└────────────┘

┌─SecondTable─┐
│           0 │
│           0 │
│           0 │
│           1 │
│           1 │
└─────────────┘

Notez que ce paramètre influe sur le comportement des vues matérialisées.

​

optimize_or_like_chain

Optimise plusieurs expressions OR LIKE en multiMatchAny. Cette optimisation ne doit pas être activée par défaut, car dans certains cas, elle empêche l’analyse des index.

​

optimize_prewhere_after_pushdown

Exécute une seconde passe de promotion de PREWHERE après que des optimisations ultérieures du plan de requête ont pu ajouter des filtres supplémentaires au-dessus d’une étape de lecture MergeTree (par ex. pushdown de prédicats via JOIN, réécritures de projection). Lorsqu’un PREWHERE existe déjà, le nouveau filtre y est fusionné avec AND au lieu de rester une étape de filtrage distincte.

​

optimize_qbit_distance_function_reads

Remplace les fonctions de distance sur le type de données QBit par des fonctions équivalentes qui ne lisent dans le stockage que les colonnes nécessaires au calcul.

​

optimize_read_in_order

Active l’optimisation de ORDER BY dans les requêtes SELECT lors de la lecture de données à partir des tables MergeTree.

Valeurs possibles :

• 0 — l’optimisation ORDER BY est désactivée.
• 1 — l’optimisation ORDER BY est activée.

Voir aussi

• Clause ORDER BY

​

optimize_redundant_functions_in_order_by

Supprime les fonctions de ORDER BY lorsque leur argument figure également dans ORDER BY

​

optimize_respect_aliases

Si ce paramètre est défini sur true, les alias seront pris en compte dans WHERE/GROUP BY/ORDER BY, ce qui contribuera à l’élagage des partitions, aux index secondaires, à optimize_aggregation_in_order, à optimize_read_in_order et à optimize_trivial_count

​

optimize_rewrite_aggregate_function_with_if

Réécrit les fonctions d’agrégation dont l’argument est une expression if, lorsqu’elles sont logiquement équivalentes. Par exemple, avg(if(cond, col, null)) peut être réécrit en avgOrNullIf(cond, col). Cela peut améliorer les performances.

Pris en charge uniquement avec l’analyseur (enable_analyzer = 1).

​

optimize_rewrite_array_exists_to_has

Réécrit les fonctions arrayExists() en has() lorsqu’elles sont logiquement équivalentes. Par exemple, arrayExists(x -> x = 1, arr) peut être réécrit en has(arr, 1)

​

optimize_rewrite_has_to_in

Réécrit les fonctions has en IN lorsque le premier argument est un Array constant. Par exemple, has([1, 2, 3], x) peut être réécrit en x IN [1, 2, 3] pour de meilleures performances avec des Array constants

​

optimize_rewrite_like_perfect_affix

Réécrit les expressions LIKE avec un préfixe ou un suffixe exact (par ex. col LIKE 'ClickHouse%') en appels aux fonctions startsWith ou endsWith (par ex. startsWith(col, 'ClickHouse')).

​

optimize_rewrite_regexp_functions

Réécrit les fonctions liées aux expressions régulières sous des formes plus simples et plus performantes

​

optimize_rewrite_sum_if_to_count_if

Réécrit les fonctions sumIf() et sum(if()) en countIf() lorsqu’elles sont logiquement équivalentes

​

optimize_skip_merged_partitions

Active ou désactive l’optimisation de la requête OPTIMIZE TABLE … FINAL lorsqu’il n’existe qu’une seule partie avec un niveau > 0 et qu’elle n’a pas de TTL expiré.

• OPTIMIZE TABLE ... FINAL SETTINGS optimize_skip_merged_partitions=1

Par défaut, la requête OPTIMIZE TABLE ... FINAL réécrit cette partie même s’il n’en existe qu’une seule.

Valeurs possibles :

• 1 - Activer l’optimisation.
• 0 - Désactiver l’optimisation.

​

optimize_skip_unused_shards

Active ou désactive l’omission des shards inutilisés pour les requêtes SELECT qui comportent une condition sur la clé de sharding dans WHERE/PREWHERE, et active les optimisations associées pour les requêtes distribuées (par exemple, l’agrégation par clé de sharding).

Suppose que les données sont distribuées selon la clé de sharding ; sinon, la requête renvoie un résultat incorrect.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

optimize_skip_unused_shards_limit

Limite du nombre de valeurs de la clé de sharding ; désactive optimize_skip_unused_shards si cette limite est atteinte.

Un trop grand nombre de valeurs peut nécessiter beaucoup de ressources de traitement, pour un bénéfice incertain, car si vous avez un très grand nombre de valeurs dans IN (...), la requête sera très probablement envoyée à tous les shards de toute façon.

​

optimize_skip_unused_shards_nesting

Contrôle le comportement de optimize_skip_unused_shards en fonction du niveau d’imbrication de la requête distribuée (cela nécessite donc toujours optimize_skip_unused_shards). Cela correspond au cas où une table Distributed interroge une autre table Distributed.

Valeurs possibles :

• 0 — Désactivé, optimize_skip_unused_shards fonctionne toujours.
• 1 — Active optimize_skip_unused_shards uniquement pour le premier niveau.
• 2 — Active optimize_skip_unused_shards jusqu’au deuxième niveau.

​

optimize_skip_unused_shards_rewrite_in

Réécrit l’expression IN de la requête pour les shards distants afin d’exclure les valeurs qui n’appartiennent pas au shard (nécessite optimize_skip_unused_shards).

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

optimize_sorting_by_input_stream_properties

Optimise le tri en fonction des propriétés de tri du flux d’entrée

​

optimize_substitute_columns

Utilisez les contraintes pour substituer des colonnes. La valeur par défaut est false.

Valeurs possibles :

• true, false

​

optimize_syntax_fuse_functions

Active la fusion des fonctions d’agrégation ayant le même argument. Réécrit les requêtes contenant au moins deux fonctions d’agrégation parmi sum, count ou avg avec le même argument en sumCount.

Valeurs possibles :

• 0 — Les fonctions ayant le même argument ne sont pas fusionnées.
• 1 — Les fonctions ayant le même argument sont fusionnées.

Exemple

Requête :

CREATE TABLE fuse_tbl(a Int8, b Int8) Engine = Log;
SET optimize_syntax_fuse_functions = 1;
EXPLAIN SYNTAX run_query_tree_passes = 1 SELECT sum(a), sum(b), count(b), avg(b) from fuse_tbl FORMAT TSV;

Résultat :

SELECT
    sum(__table1.a) AS `sum(a)`,
    tupleElement(sumCount(__table1.b), 1) AS `sum(b)`,
    tupleElement(sumCount(__table1.b), 2) AS `count(b)`,
    divide(tupleElement(sumCount(__table1.b), 1), toFloat64(tupleElement(sumCount(__table1.b), 2))) AS `avg(b)`
FROM default.fuse_tbl AS __table1

​

optimize_throw_if_noop

Active ou désactive le déclenchement d’une exception si une requête OPTIMIZE n’a effectué aucune fusion.

Par défaut, OPTIMIZE se termine avec succès même s’il n’a rien fait. Ce paramètre vous permet de distinguer ces situations et d’obtenir la raison dans un message d’exception.

Valeurs possibles :

• 1 — Le déclenchement d’une exception est activé.
• 0 — Le déclenchement d’une exception est désactivé.

​

optimize_time_filter_with_preimage

Optimiser les prédicats Date et DateTime en convertissant les fonctions en comparaisons équivalentes, sans conversion (par ex. toYear(col) = 2023 -> col >= '2023-01-01' AND col <= '2023-12-31')

​

optimize_trivial_approximate_count_query

Utilise une valeur approximative pour l’optimisation des requêtes count triviales sur les moteurs de stockage qui prennent en charge ce type d’estimation, par exemple EmbeddedRocksDB.

Valeurs possibles :

• 0 — Optimisation désactivée.
  • 1 — Optimisation activée.

​

optimize_trivial_count_query

Active ou désactive l’optimisation de la requête triviale SELECT count() FROM table à l’aide des métadonnées de MergeTree. Si vous devez utiliser la sécurité au niveau des lignes, désactivez ce paramètre.

Valeurs possibles :

• 0 — Optimisation désactivée.
  • 1 — Optimisation activée.

Voir aussi :

• optimize_functions_to_subcolumns

​

optimize_trivial_group_by_limit_query

Active ou désactive l’optimisation d’une requête triviale SELECT key_expr FROM table GROUP BY key_expr LIMIT n (sans fonctions d’agrégation dans la projection, sans clauses HAVING/ORDER BY/LIMIT BY/window, et sans modificateurs GROUP BY) en définissant max_rows_to_group_by = n + offset avec group_by_overflow_mode = 'any'. L’agrégation s’arrête dès que n + offset clés distinctes ont été produites.

L’optimisation est désactivée lorsque l’utilisateur a explicitement défini group_by_overflow_mode sur une valeur autre que any (afin de préserver le comportement explicite throw/break), ainsi que lorsque l’utilisateur a déjà défini un max_rows_to_group_by plus restrictif (l’optimisation serait alors sans effet).

Valeurs possibles :

• 0 — Optimisation désactivée.
  • 1 — Optimisation activée.

​

optimize_trivial_insert_select

Optimiser la requête triviale INSERT INTO table SELECT ... FROM TABLES

​

optimize_truncate_order_by_after_group_by_keys

Supprime les éléments ORDER BY finaux une fois que toutes les clés du GROUP BY sont incluses dans le préfixe ORDER BY.

​

optimize_uniq_to_count

Réécrit uniq et ses variantes (sauf uniqUpTo) en count si la sous-requête contient DISTINCT ou une clause GROUP BY.

​

optimize_use_implicit_projections

Sélectionne automatiquement les projections implicites pour exécuter la requête SELECT

​

optimize_use_projection_filtering

Permet d’utiliser les projections pour filtrer les plages de parts, même lorsque les projections ne sont pas sélectionnées pour exécuter la requête SELECT.

​

optimize_use_projections

Alias : allow_experimental_projection_optimization

Active ou désactive l’optimisation des projections pendant le traitement des requêtes SELECT.

Valeurs possibles :

• 0 — Optimisation des projections désactivée.
• 1 — Optimisation des projections activée.

​

optimize_using_constraints

Utilisez les contraintes pour optimiser les requêtes. La valeur par défaut est false.

Valeurs possibles :

• true, false

​

os_threads_nice_value_materialized_view

Valeur nice Linux pour les threads des vues matérialisées. Plus la valeur est faible, plus la priorité CPU est élevée.

Nécessite la capacité CAP_SYS_NICE, sinon aucun effet.

Valeurs possibles : -20 à 19.

​

os_threads_nice_value_query

Alias : os_thread_priority

Valeur nice Linux pour les threads de traitement des requêtes. Plus la valeur est faible, plus la priorité CPU est élevée.

Nécessite la capacité CAP_SYS_NICE, sinon aucun effet.

Valeurs possibles : -20 à 19.

​

page_cache_block_size

Taille des fragments de fichier à stocker dans le cache de pages en espace utilisateur, en octets. Toutes les lectures qui passent par le cache seront arrondies au multiple supérieur de cette taille.

Ce paramètre peut être ajusté au niveau de chaque requête, mais les entrées de cache avec des tailles de bloc différentes ne peuvent pas être réutilisées. Modifier ce paramètre invalide de fait les entrées existantes du cache.

Une valeur plus élevée, comme 1 MiB, convient bien aux requêtes à haut débit, tandis qu’une valeur plus faible, comme 64 KiB, convient bien aux requêtes ponctuelles à faible latence.

​

page_cache_inject_eviction

Le cache de pages en espace utilisateur invalide parfois certaines pages de façon aléatoire. Destiné aux tests.

​

page_cache_lookahead_blocks

Lorsqu’il y a un défaut dans le cache de pages en espace utilisateur, jusqu’à ce nombre de blocs consécutifs sont lus en une seule fois depuis le stockage sous-jacent, s’ils ne se trouvent pas non plus dans le cache. Chaque bloc fait page_cache_block_size octets.

Une valeur plus élevée est bénéfique pour les requêtes à haut débit, tandis que les requêtes ponctuelles à faible latence fonctionneront mieux sans prélecture.

​

page_cache_max_coalesced_bytes

Lorsque readBigAt alimente le cache de pages en espace utilisateur, les défauts de cache consécutifs sont regroupés en une seule lecture depuis le stockage sous-jacent. Ce paramètre limite la taille, en octets, d’une lecture coalescée ; les séries de défauts plus longues sont divisées en plusieurs lectures. Il limite l’utilisation transitoire de la mémoire du tampon temporaire lors de lectures à froid parallèles.

Une valeur plus élevée réduit le nombre de requêtes HTTP lors de scans à froid sur le stockage objet ; une valeur plus faible réduit le pic de mémoire transitoire.

​

paimon_target_snapshot_id

Lecture ciblée d’un instantané au niveau de la requête pour le mode incrémental de Paimon. Lorsque >0, le lecteur récupère uniquement le delta pour le snapshot_id spécifié sans faire avancer le watermark validé. Par défaut : -1 (désactivé)

​

parallel_distributed_insert_select

Active l’exécution parallèle des requêtes distribuées INSERT ... SELECT.

Si l’on exécute des requêtes INSERT INTO distributed_table_a SELECT ... FROM distributed_table_b, que les deux tables utilisent le même cluster et qu’elles sont toutes deux soit répliquées, soit non répliquées, alors la requête est traitée localement sur chaque shard.

Valeurs possibles :

• 0 — Désactivé.
• 1 — SELECT sera exécuté sur chaque shard à partir de la table sous-jacente du moteur Distributed.
• 2 — SELECT et INSERT seront exécutés sur chaque shard, à partir de/vers la table sous-jacente du moteur Distributed.

Depuis la version 25.4, INSERT ... SELECT à partir d’une source ReplicatedMergeTree ou SharedMergeTree peut également être parallélisé entre les répliques. Pour l’activer :

• parallel_distributed_insert_select = 2
• enable_parallel_replicas = 1

​

parallel_hash_join_threshold

Lorsque l’algorithme de jointure fondé sur le hachage est utilisé, ce seuil aide à déterminer s’il faut utiliser hash ou parallel_hash (uniquement si une estimation de la taille de la table de droite est disponible). Le premier est utilisé lorsque nous savons que la taille de la table de droite est inférieure au seuil.

​

parallel_non_joined_rows_processing

Autorise plusieurs threads à traiter en parallèle les lignes non jointes de la table de droite lors des JOIN RIGHT et FULL. Cela peut accélérer la phase de traitement des lignes non jointes lors de l’utilisation de l’algorithme de jointure parallel_hash avec de grandes tables. Lorsqu’il est désactivé, les lignes non jointes sont traitées par un seul thread.

​

parallel_replica_offset

Il s’agit d’un paramètre interne qui ne doit pas être utilisé directement et qui correspond à un détail d’implémentation du mode « répliques parallèles ». Ce paramètre sera automatiquement défini par le serveur initiateur, pour les requêtes distribuées, sur l’index de la réplique participant au traitement de la requête parmi les répliques parallèles.

​

parallel_replicas_allow_in_with_subquery

Si la valeur est true, la sous-requête de IN sera exécutée sur chaque réplique suiveuse.

​

parallel_replicas_allow_materialized_views

Autoriser l’utilisation des vues matérialisées avec les répliques parallèles

​

parallel_replicas_allow_view_over_mergetree

Autorise les répliques parallèles à exécuter la requête externe d’une vue simple sur des tables MergeTree (au lieu de la requête interne de la vue), ce qui améliore la parallélisation entre les nœuds. S’applique également aux vues UNION ALL dont toutes les branches lisent chacune dans des tables MergeTree différentes.

​

parallel_replicas_connect_timeout_ms

Le délai d’attente, en millisecondes, pour établir une connexion à une réplique distante lors de l’exécution d’une requête avec des répliques parallèles. Si le délai d’attente expire, la réplique correspondante n’est pas utilisée pour l’exécutio

​

parallel_replicas_count

Ce paramètre interne ne doit pas être utilisé directement et correspond à un détail d’implémentation du mode « répliques parallèles ». Il sera automatiquement défini par le serveur initiateur, pour les requêtes distribuées, sur le nombre de répliques parallèles participant au traitement de la requête.

​

parallel_replicas_custom_key

Expression entière arbitraire pouvant être utilisée pour répartir la charge entre les répliques d’une table donnée. La valeur peut être n’importe quelle expression entière.

Il est préférable d’utiliser des expressions simples basées sur les clés primaires.

Si ce paramètre est utilisé sur un cluster composé d’un seul shard avec plusieurs répliques, ces répliques seront converties en shards virtuels. Sinon, il se comportera de la même manière que pour la clé SAMPLE : il utilisera plusieurs répliques de chaque shard.

​

parallel_replicas_custom_key_range_lower

Permet au filtre de type range de répartir uniformément le travail entre les répliques en fonction de la plage personnalisée [parallel_replicas_custom_key_range_lower, INT_MAX].

Lorsqu’il est utilisé conjointement avec parallel_replicas_custom_key_range_upper, il permet au filtre de répartir uniformément le travail entre les répliques pour la plage [parallel_replicas_custom_key_range_lower, parallel_replicas_custom_key_range_upper].

Remarque : ce paramètre n’entraîne pas le filtrage de données supplémentaires pendant le traitement des requêtes ; il modifie plutôt les points auxquels le filtre de plage découpe la plage [0, INT_MAX] pour le traitement parallèle.

​

parallel_replicas_custom_key_range_upper

Permet au filtre de type range de répartir uniformément le travail entre les répliques en fonction de la plage personnalisée [0, parallel_replicas_custom_key_range_upper]. Une valeur de 0 désactive la borne supérieure et la définit sur la valeur maximale de l’expression de clé personnalisée.

Lorsqu’il est utilisé conjointement avec parallel_replicas_custom_key_range_lower, il permet au filtre de répartir uniformément le travail entre les répliques sur la plage [parallel_replicas_custom_key_range_lower, parallel_replicas_custom_key_range_upper].

Remarque : ce paramètre n’entraîne pas le filtrage de données supplémentaires pendant le traitement des requêtes ; il modifie plutôt les points auxquels le filtre de plage découpe la plage [0, INT_MAX] pour le traitement parallèle

​

parallel_replicas_filter_pushdown

Permet de pousser les filtres vers la partie de la requête exécutée par les répliques parallèles

​

parallel_replicas_for_cluster_engines

Remplacer les moteurs de fonctions de table par leurs équivalents -Cluster

​

parallel_replicas_for_non_replicated_merge_tree

Si la valeur est true, ClickHouse utilisera également l’algorithme des répliques parallèles pour les tables MergeTree non répliquées

​

parallel_replicas_index_analysis_only_on_coordinator

Analyse des index effectuée uniquement sur la réplique coordinatrice et ignorée sur les autres répliques. Prend effet uniquement lorsque parallel_replicas_local_pla est activé

​

parallel_replicas_insert_select_local_pipeline

Utiliser le pipeline local pour un INSERT SELECT distribué avec des répliques parallèles

​

parallel_replicas_local_plan

Construire un plan local pour la réplique locale

​

parallel_replicas_mark_segment_size

Les parts sont virtuellement divisées en segments afin d’être réparties entre les répliques pour une lecture parallèle. Ce paramètre contrôle la taille de ces segments. Il n’est pas recommandé de le modifier tant que vous n’êtes pas absolument certain de ce que vous faites. La valeur doit être comprise dans l’intervalle [128; 16384]

​

parallel_replicas_min_number_of_rows_per_replica

Limite le nombre de répliques utilisées dans une requête à (nombre estimé de lignes à lire / min_number_of_rows_per_replica). Le maximum reste toutefois limité par ‘max_parallel_replicas’

​

parallel_replicas_mode

Type de filtre à utiliser avec une clé personnalisée pour les répliques parallèles. default - utilise l’opération modulo sur la clé personnalisée, range - utilise un filtre de plage sur la clé personnalisée en se servant de toutes les valeurs possibles du type de valeur de la clé personnalisée.

​

parallel_replicas_only_with_analyzer

L’analyseur doit être activé pour utiliser les répliques parallèles. Lorsque l’analyseur est désactivé, l’exécution de la requête revient à une exécution locale, même si la lecture parallèle depuis les répliques est activée. L’utilisation des répliques parallèles sans l’analyseur activé n’est pas prise en charge

​

parallel_replicas_prefer_local_join

Si cette valeur est true, que JOIN peut être exécuté avec l’algorithme de réplique parallèle et que tous les moteurs de stockage de la partie droite du JOIN sont de type *MergeTree, un JOIN local sera utilisé au lieu de GLOBAL JOIN.

​

parallel_replicas_prefer_local_replica

Lorsqu’elle est activée (par défaut), la réplique locale est toujours incluse dans l’ensemble des répliques utilisées pour la lecture parallèle. Lorsqu’elle est désactivée, la réplique locale ne bénéficie d’aucune préférence et les répliques sont sélectionnées uniquement par l’algorithme d’équilibrage de charge. Cela permet d’acheminer les requêtes avec max_parallel_replicas = 1 vers un autre hôte, ce qui peut améliorer la localité de cache lorsque de nombreuses requêtes courtes sont réparties sur un cluster.

​

parallel_replicas_support_projection

L’optimisation des projections peut être appliquée sur des répliques parallèles. N’a d’effet que si parallel_replicas_local_plan est activé et que aggregation_in_order est inactif.

​

parallel_view_processing

Active l’envoi vers les vues attachées en parallèle plutôt que de façon séquentielle.

​

parallelize_output_from_storages

Parallélise la sortie à l’étape de lecture depuis le stockage. Cela permet de paralléliser le traitement des requêtes immédiatement après la lecture depuis le stockage, lorsque c’est possible

​

parsedatetime_e_requires_space_padding

Le spécificateur de format ‘%e’ dans la fonction ‘parseDateTime’ exige que les jours sur un seul chiffre soient complétés par des espaces. Par exemple, ’ 2’ est accepté, mais ‘2’ génère une erreur.

​

parsedatetime_parse_without_leading_zeros

Les spécificateurs de format ‘%c’, ‘%l’ et ‘%k’ de la fonction ‘parseDateTime’ analysent les mois et les heures sans zéro non significatif.

​

partial_merge_join_left_table_buffer_bytes

Si cette valeur n’est pas 0, regroupe les blocs de la table de gauche en blocs plus volumineux pour la table de gauche dans la jointure par fusion partielle. Utilise jusqu’à 2x la mémoire spécifiée par thread de jointure.

​

partial_merge_join_rows_in_right_blocks

Limite la taille des blocs de données de la partie droite de la jointure dans l’algorithme de jointure par fusion partielle pour les requêtes JOIN.

Le serveur ClickHouse :

1. Divise les données de la partie droite de la jointure en blocs contenant jusqu’au nombre de lignes spécifié.
2. Indexe chaque bloc avec ses valeurs minimale et maximale.
3. Décharge les blocs préparés sur le disk si possible.

Valeurs possibles :

• Tout entier positif. Plage de valeurs recommandée : [1000, 100000].

​

partial_result_on_first_cancel

Permet à une requête de renvoyer un résultat partiel après annulation.

​

parts_to_delay_insert

Si la table de destination contient au moins ce nombre de parts actives dans une seule partition, les insertions dans la table sont artificiellement ralenties.

​

parts_to_throw_insert

Si le nombre de parts actives dans une même partition de la table de destination dépasse cette valeur, l’exception ‘Too many parts …’ est levée.

​

per_part_index_stats

Consigne les statistiques d’index pour chaque part

​

poll_interval

Bloque la boucle d’attente des requêtes sur le serveur pendant le nombre de secondes spécifié.

​

polyglot_dialect

Dialecte SQL source du transpileur polyglotte (par exemple, ‘sqlite’, ‘mysql’, ‘postgresql’, ‘snowflake’, ‘duckdb’).

​

postgresql_connection_attempt_timeout

Délai d’expiration, en secondes, d’une tentative unique de connexion au point de terminaison PostgreSQL. La valeur est transmise comme paramètre connect_timeout dans l’URL de connexion.

​

postgresql_connection_pool_auto_close_connection

Fermer la connexion avant de la renvoyer au pool de connexions.

​

postgresql_connection_pool_retries

Nombre de tentatives push/pop du pool de connexions pour le moteur de table et le moteur de base de données PostgreSQL.

​

postgresql_connection_pool_size

Taille du pool de connexions pour le moteur de table PostgreSQL et le moteur de base de données.

​

postgresql_connection_pool_wait_timeout

Délai d’expiration des opérations push/pop du pool de connexions lorsque celui-ci est vide, pour le moteur de table PostgreSQL et le moteur de base de données. Par défaut, l’opération reste bloquante lorsque le pool est vide.

​

postgresql_fault_injection_probability

Probabilité approximative d’échec des requêtes PostgreSQL internes (utilisées pour la réplication). La valeur valide se situe dans l’intervalle [0.0f, 1.0f]

​

predicate_statistics_sample_rate

Collecte les statistiques de sélectivité des prédicats dans system.predicate_statistics_log. Lorsqu’il est défini sur N > 0, environ 1/N des requêtes sont échantillonnées (selon l’ID de requête). 0 signifie que cette fonctionnalité est désactivée.

​

prefer_column_name_to_alias

Active ou désactive l’utilisation des noms de colonnes d’origine à la place des alias dans les expressions et les clauses de requête. Cela est particulièrement important lorsque l’alias est identique au nom de la colonne, voir Expression Aliases. Activez ce paramètre pour rendre les règles de syntaxe des alias dans ClickHouse plus compatibles avec celles de la plupart des autres moteurs de base de données.

Valeurs possibles :

• 0 — Le nom de la colonne est remplacé par l’alias.
• 1 — Le nom de la colonne n’est pas remplacé par l’alias.

Exemple

Différence entre l’option activée et désactivée :

Requête :

SET prefer_column_name_to_alias = 0;
SELECT avg(number) AS number, max(number) FROM numbers(10);

Résultat :

Received exception from server (version 21.5.1):
Code: 184. DB::Exception: Received from localhost:9000. DB::Exception: Aggregate function avg(number) is found inside another aggregate function in query: While processing avg(number) AS number.

Requête :

SET prefer_column_name_to_alias = 1;
SELECT avg(number) AS number, max(number) FROM numbers(10);

Résultat :

┌─number─┬─max(number)─┐
│    4.5 │           9 │
└────────┴─────────────┘

​

prefer_external_sort_block_bytes

Préférer la taille de bloc maximale pour le tri externe afin de réduire l’utilisation de la mémoire lors de la fusion.

​

prefer_global_in_and_join

Active le remplacement des opérateurs IN/JOIN par GLOBAL IN/GLOBAL JOIN.

Valeurs possibles :

• 0 — Désactivé. Les opérateurs IN/JOIN ne sont pas remplacés par GLOBAL IN/GLOBAL JOIN.
• 1 — Activé. Les opérateurs IN/JOIN sont remplacés par GLOBAL IN/GLOBAL JOIN.

Utilisation

Bien que SET distributed_product_mode=global puisse modifier le comportement des requêtes sur les tables distribuées, cela ne convient pas aux tables locales ni aux tables issues de ressources externes. C’est là que le paramètre prefer_global_in_and_join entre en jeu.

Par exemple, nous pouvons avoir des nœuds qui traitent les requêtes et contiennent des tables locales, qui ne se prêtent pas à une distribution. Nous devons répartir leurs données à la volée pendant le traitement distribué à l’aide du mot-clé GLOBAL — GLOBAL IN/GLOBAL JOIN.

Un autre cas d’usage de prefer_global_in_and_join est l’accès à des tables créées par des moteurs externes. Ce paramètre permet de réduire le nombre d’appels aux sources externes lors de la jointure de telles tables : un seul appel par requête.

Voir aussi :

• Sous-requêtes distribuées pour plus d’informations sur l’utilisation de GLOBAL IN/GLOBAL JOIN

​

prefer_localhost_replica

Active ou désactive l’utilisation préférentielle de la réplique localhost lors du traitement des requêtes distribuées.

Valeurs possibles :

• 1 — ClickHouse envoie toujours une requête à la réplique localhost si elle existe.
• 0 — ClickHouse utilise la stratégie d’équilibrage spécifiée par le paramètre load_balancing.

Désactivez ce paramètre si vous utilisez max_parallel_replicas sans parallel_replicas_custom_key. Si parallel_replicas_custom_key est défini, désactivez ce paramètre uniquement s’il est utilisé sur un cluster comportant plusieurs shards avec plusieurs répliques. S’il est utilisé sur un cluster comportant un seul shard et plusieurs répliques, la désactivation de ce paramètre aura des effets négatifs.

​

prefer_warmed_unmerged_parts_seconds

N’a d’effet que dans ClickHouse Cloud. Si une part fusionnée date de moins de ce nombre de secondes et n’est pas préchauffée (voir cache_populated_by_fetch), mais que toutes ses parts sources sont disponibles et préchauffées, les requêtes SELECT liront ces parts à la place. Uniquement pour Replicated-/SharedMergeTree. Notez que cela vérifie uniquement si CacheWarmer a traité la part ; si la part a été mise en cache par un autre mécanisme, elle sera quand même considérée comme froide jusqu’à ce que CacheWarmer la traite ; si elle a été préchauffée puis évincée du cache, elle sera quand même considérée comme chaude.

​

preferred_block_size_bytes

Ce paramètre ajuste la taille du bloc de données pour le traitement des requêtes et affine le paramètre plus grossier ‘max_block_size’. Si les colonnes sont volumineuses et que, avec ‘max_block_size’ lignes, la taille du bloc risque de dépasser le nombre d’octets spécifié, elle sera réduite afin d’améliorer la localité du cache CPU.

​

preferred_max_column_in_block_size_bytes

Limite de la taille maximale d’une colonne dans un bloc lors de la lecture. Permet de réduire le nombre de défauts de cache. Elle doit être proche de la taille du cache L2.

​

preferred_optimize_projection_name

S’il est défini sur une chaîne de caractères non vide, ClickHouse essaiera d’appliquer la projection spécifiée dans la requête.

Valeurs possibles :

• String : nom de la projectio préférée

​

prefetch_buffer_size

La taille maximale du tampon de prélecture pour la lecture depuis le système de fichiers.

​

print_pretty_type_names

Permet d’afficher de façon lisible les noms de types profondément imbriqués, avec indentation, dans la query DESCRIBE et dans la fonction toTypeName().

Exemple :

CREATE TABLE test (a Tuple(b String, c Tuple(d Nullable(UInt64), e Array(UInt32), f Array(Tuple(g String, h Map(String, Array(Tuple(i String, j UInt64))))), k Date), l Nullable(String))) ENGINE=Memory;
DESCRIBE TABLE test FORMAT TSVRaw SETTINGS print_pretty_type_names=1;

a   Tuple(
    b String,
    c Tuple(
        d Nullable(UInt64),
        e Array(UInt32),
        f Array(Tuple(
            g String,
            h Map(
                String,
                Array(Tuple(
                    i String,
                    j UInt64
                ))
            )
        )),
        k Date
    ),
    l Nullable(String)
)

​

priority

Priorité de la requête. 1 - la plus élevée, plus la valeur est grande, plus la priorité est faible ; 0 - ne pas utiliser de priorités.

​

promql_database

Spécifie le nom de la base de données utilisé par le dialecte ‘promql’. Une chaîne vide désigne la base de données actuelle.

​

promql_evaluation_time

Alias : evaluation_time

Définit l’heure d’évaluation à utiliser pour le dialecte promql. ‘auto’ signifie l’heure actuelle.

​

promql_table

Indique le nom d’une table TimeSeries utilisée par le dialecte ‘promql’.

​

push_external_roles_in_interserver_queries

Active la propagation des rôles utilisateur du nœud initiateur vers les autres nœuds lors de l’exécution d’une requête.

​

query_cache_compress_entries

Compresse les entrées du cache de requêtes. Réduit la consommation mémoire du cache de requêtes, au prix d’insertions et de lectures plus lentes.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

query_cache_for_subqueries

Lorsqu’elle est activée, les résultats des sous-requêtes peuvent être écrits dans le cache de requêtes et lus depuis celui-ci. Cela permet de propager use_query_cache à toutes les sous-requêtes.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

query_cache_max_entries

Le nombre maximal de résultats de requête que l’utilisateur courant peut stocker dans le cache de requête. 0 signifie qu’il n’y a pas de limite.

Valeurs possibles :

• Entier positif >= 0.

​

query_cache_max_size_in_bytes

La quantité maximale de mémoire (en octets) que l’utilisateur courant peut allouer dans le cache de requêtes. 0 signifie qu’il n’y a pas de limite.

Valeurs possibles :

• Entier supérieur ou égal à 0.

​

query_cache_min_query_duration

Durée minimale, en millisecondes, pendant laquelle une requête doit s’exécuter pour que son résultat soit stocké dans le cache de requêtes.

Valeurs possibles :

• Entier >= 0.

​

query_cache_min_query_runs

Nombre minimum d’exécutions d’une requête SELECT avant que son résultat ne soit stocké dans le cache des requêtes.

Valeurs possibles :

• Entier >= 0.

​

query_cache_nondeterministic_function_handling

Contrôle la façon dont le cache de requêtes gère les requêtes SELECT contenant des fonctions non déterministes comme rand() ou now().

Valeurs possibles :

• 'throw' - Déclenche une exception et ne met pas en cache le résultat de la requête.
• 'save' - Met en cache le résultat de la requête.
• 'ignore' - Ne met pas en cache le résultat de la requête et ne déclenche pas d’exception.

​

query_cache_share_between_users

Si cette option est activée, le résultat des requêtes SELECT mis en cache dans le cache de requête peut être consulté par d’autres utilisateurs. Il n’est pas recommandé d’activer ce paramètre pour des raisons de sécurité.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

query_cache_squash_partial_results

Regroupe les blocs de résultats partiels en blocs de taille max_block_size. Réduit les performances lors des insertions dans le cache de requête, mais améliore la compressibilité des entrées du cache (voir query_cache_compress-entries).

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

query_cache_system_table_handling

Contrôle la façon dont le cache de requêtes gère les requêtes SELECT sur les tables système, c’est-à-dire les tables des bases de données system.* et information_schema.*.

Valeurs possibles :

• 'throw' - Lever une exception et ne pas mettre en cache le résultat de la requête.
• 'save' - Mettre en cache le résultat de la requête.
• 'ignore' - Ne pas mettre en cache le résultat de la requête et ne pas lever d’exception.

​

query_cache_tag

Une chaîne de caractères servant d’étiquette pour les entrées du cache de requêtes. Les mêmes requêtes avec des étiquettes différentes sont considérées comme différentes par le cache de requêtes.

Valeurs possibles :

• Toute chaîne de caractères

​

query_cache_ttl

Après ce délai, en secondes, les entrées du cache de requête deviennent obsolètes.

Valeurs possibles :

• Entier positif >= 0.

​

query_metric_log_interval

L’intervalle, en millisecondes, auquel le query_metric_log est collecté pour chaque requête.

S’il est défini sur une valeur négative, il prendra la valeur collect_interval_milliseconds du paramètre query_metric_log, ou 1000 par défaut si celle-ci n’est pas définie.

Pour désactiver la collecte pour une requête unique, définissez query_metric_log_interval sur 0.

Valeur par défaut : -1

​

query_plan_aggregation_in_order

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

Il s’agit d’un paramètre de niveau expert qui ne doit être utilisé par les développeurs qu’à des fins de débogage. Ce paramètre peut évoluer ultérieurement de manière non rétrocompatible, ou être supprimé.

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 appliqué après le JOIN s’évalue 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 ne dépendent que de la table de gauche. Peut produire des résultats incorrects avec des jointures autres que ANY JOIN (par exemple les ALL JOIN, qui constituent le comportement par défaut).

​

query_plan_convert_outer_join_to_inner_join

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

​

query_plan_direct_read_from_text_index

Permet d’effectuer le filtrage de recherche plein texte en n’utilisant que 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 une fois les fonctions de fenêtre évaluées 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.

Il s’agit d’un paramètre réservé aux experts, qui ne doit être utilisé par les développeurs qu’à des fins de débogage. Ce paramètre pourra, à l’avenir, être modifié de manière non rétrocompatible ou supprimé.

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 propres paramètres)

​

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 opérations de tri. N’a d’effet que si le paramètre query_plan_enable_optimizations est défini sur 1.

Il s’agit d’un paramètre destiné aux experts, qui ne doit être utilisé pour le débogage que par les développeurs. Ce paramètre pourra évoluer ultérieurement de manière non rétrocompatible, voire être supprimé.

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 pousse les filtres vers le bas dans le plan d’exécution. N’a d’effet que si le paramètre query_plan_enable_optimizations vaut 1.

Il s’agit d’un paramètre destiné aux experts, qui ne doit être utilisé par les développeurs qu’à des fins de débogage. Ce paramètre peut être modifié ultérieurement de manière non rétrocompatible, voire supprimé.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

​

query_plan_join_shard_by_pk_ranges

Applique le sharding aux JOIN si les clés de jointure contiennent un préfixe de PRIMARY KEY dans les deux tables. Pris en charge avec les algorithmes hash, parallel_hash et 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 quel côté de la jointure doit servir de table de build (également appelée table interne, c’est-à-dire celle insérée dans la table de hachage pour une jointure par hachage) dans le plan de requête. Ce paramètre n’est pris en charge que pour la strictness de jointure ALL avec la clause JOIN ON. Les valeurs possibles sont :

• ‘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. Ne prend effet que si le paramètre query_plan_enable_optimizations vaut 1.

Il s’agit d’un paramètre de niveau expert qui ne doit être utilisé à des fins de débogage que par les développeurs. Ce paramètre pourra, à l’avenir, changer de manière incompatible avec les versions précédentes ou être supprimé.

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 déplace des sous-arbres plus importants du plan de requête vers union afin de permettre d’autres optimisations. Ne prend effet que si le paramètre query_plan_enable_optimizations vaut 1.

Il s’agit d’un paramètre réservé aux experts, qui ne doit être utilisé par les développeurs qu’à des fins de débogage. Ce paramètre peut évoluer ultérieurement de manière non rétrocompatible, voire être supprimé.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

​

query_plan_max_limit_for_join_lazy_indexing

Contrôle la valeur maximale de limite permettant d’utiliser le plan de requête pour l’optimisation d’indexation paresseuse des JOIN. Si cette valeur est égale à 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 paresseuse. Si elle 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 permettant d’évaluer le plan de requête pour l’optimisation TopK à l’aide de l’index de saut minmax et du filtrage dynamique par seuil. Si cette valeur est égale à zéro, aucune limite n’est appliquée.

​

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. Utile pour éviter des temps d’optimisation trop longs pour les requêtes complexes. Avec la requête EXPLAIN PLAN, l’application des optimisations s’arrête une fois cette limite atteinte et le plan est renvoyé tel quel. Lors de l’exécution normale d’une requête, si le nombre réel d’optimisations dépasse ce paramètre, une exception est levée.

Il s’agit d’un paramètre destiné aux experts, qui ne doit être utilisé pour le débogage que par les développeurs. Ce paramètre peut évoluer à l’avenir de manière non rétrocompatible, voire être supprimé.

​

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 limite sont considérés comme non correspondants et n’utilisent pas la projection. 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 (ainsi que 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) en fonction du 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’une étape dans EXPLAIN PLAN.

​

query_plan_merge_expressions

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

Il s’agit d’un paramètre réservé aux experts, qui ne doit être utilisé à des fins de débogage que par les développeurs. Ce paramètre pourra, à l’avenir, être modifié de manière incompatible avec les versions précédentes ou être supprimé.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

​

query_plan_merge_filter_into_join_condition

Permet de fusionner le filtre dans la condition de 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 payload 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_join_order_algorithm

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

• greedy - algorithme glouton simple - fonctionne rapidement, mais peut ne pas produire le meilleur ordre de jointure
• dpsize - implémente l’algorithme DPsize, actuellement uniquement pour les jointures internes - examine tous les ordres de jointure possibles et trouve le meilleur, 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 (programmation dynamique via partitionnement d’hypergraphe), 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 composants déconnectés), le suivant est utilisé comme solution de repli.

​

query_plan_optimize_join_order_limit

Optimise l’ordre des jointures au sein d’une même sous-requête. Cette optimisation 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 d’ordre des jointures peut énumérer avant d’abandonner et de passer à l’algorithme suivant dans query_plan_optimize_join_order_algorithm. Cela limite de manière déterministe le temps d’optimisation (indépendamment du temps écoulé) sur des graphes de jointure denses, tels que des cliques ou des étoiles, où l’espace de recherche croît de façon exponentielle. Définissez cette valeur sur 0 pour désactiver la limite. Cela n’a aucun effet avec la valeur par défaut de query_plan_optimize_join_order_limit, pour laquelle la recherche reste toujours bien en dessous de cette borne.

​

query_plan_optimize_join_order_randomize

Lorsqu’il est non nul, l’optimiseur d’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 de ReplacingMergeTree en construisant un ensemble de clés primaires, puis en l’utilisant pour l’analyse des index.

​

query_plan_optimize_lazy_materialization

Utiliser le plan de requête pour l’optimisation de la matérialisation paresseuse.

​

query_plan_optimize_prewhere

Autoriser le déplacement du filtre vers l’expression PREWHERE pour les moteurs de stockage pris en charge

​

query_plan_push_down_limit

Active ou désactive une optimisation au niveau du plan de requête qui pousse les clauses LIMIT vers le bas dans le plan d’exécution. N’a d’effet que si le paramètre query_plan_enable_optimizations vaut 1.

Il s’agit d’un paramètre de niveau expert, qui ne doit être utilisé par les développeurs qu’à des fins de débogage. Ce paramètre peut évoluer à l’avenir de manière non rétrocompatible, voire être supprimé.

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 lors de la fusion finale et dans les étapes ultérieures du pipeline. Accélère les requêtes où LIMIT BY élimine 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 dans l’ordre au niveau du plan de requête. Ne prend effet que si le paramètre query_plan_enable_optimizations est défini à 1.

Il s’agit d’un paramètre réservé aux experts, qui ne doit être utilisé par les développeurs que pour le débogage. Ce paramètre pourra à l’avenir être modifié de manière non rétrocompatible ou supprimé.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

​

query_plan_read_in_order_through_join

Préserve la lecture dans l’ordre depuis la table de gauche dans les opérations JOIN, afin qu’elle puisse être exploitée par les étapes suivantes.

​

query_plan_remove_redundant_distinct

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

Il s’agit d’un paramètre de niveau expert qui ne devrait être utilisé par les développeurs qu’à des fins de débogage. Ce paramètre pourra à l’avenir évoluer de manière non rétrocompatible ou être supprimé.

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 vaut 1.

Il s’agit d’un paramètre destiné aux experts, qui ne doit être utilisé par les développeurs que pour le débogage. Ce paramètre pourra changer ultérieurement de manière non rétrocompatible ou être supprimé.

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 visant à supprimer les colonnes inutilisées (colonnes d’entrée comme de sortie) des étapes du plan de requête. N’a d’effet que si le paramètre query_plan_enable_optimizations vaut 1.

Il s’agit d’un paramètre réservé aux experts, qui ne doit être utilisé par les développeurs qu’à des fins de débogage. Ce paramètre peut changer ultérieurement de manière non rétrocompatible, voire être supprimé.

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 s’appuie sur 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.

Il s’agit d’un paramètre de niveau expert qui ne doit être utilisé par les développeurs qu’à des fins de débogage. Ce paramètre pourra évoluer à l’avenir de manière non rétrocompatible, voire être supprimé.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

​

query_plan_split_filter

Il s’agit d’un paramètre réservé aux experts, qui ne doit être utilisé par les développeurs qu’à des fins de débogage. Ce paramètre peut être modifié ultérieurement de façon non rétrocompatible, voire supprimé.

Active ou désactive une optimisation au niveau du plan de requête qui scinde 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 une indication (prédicat supplémentaire) au 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 les colonnes du côté préservé par la jointure (LEFT/RIGHT). 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 qui tente d’utiliser l’index de similarité vectorielle. N’a d’effet que si le paramètre query_plan_enable_optimizations vaut 1.

Il s’agit d’un paramètre de niveau expert qui ne doit être utilisé que par les développeurs à des fins de débogage. Ce paramètre pourra, à l’avenir, être modifié de manière non rétrocompatible ou supprimé.

Valeurs possibles :

• 0 - Désactiver
• 1 - Activer

​

query_profiler_cpu_time_period_ns

Définit la période du minuteur d’horloge CPU du profileur de requêtes. Ce minuteur comptabilise uniquement le temps CPU.

Valeurs possibles :

• Un entier positif correspondant à un nombre de nanosecondes.

  Valeurs recommandées :

  • 10000000 (100 fois par seconde) nanosecondes et plus pour les requêtes individuelles.
  • 1000000000 (une fois par seconde) pour le profilage à l’échelle du cluster.

• 0 pour désactiver le minuteur.

Voir aussi :

• Table système trace_log

​

query_profiler_real_time_period_ns

Définit la période d’un minuteur basé sur l’horloge réelle du profileur de requêtes. Ce minuteur mesure le temps réel écoulé.

Valeurs possibles :

• Nombre entier positif, en nanosecondes.

  Valeurs recommandées :

  • 10000000 (100 fois par seconde) nanosecondes et moins pour les requêtes individuelles.
  • 1000000000 (une fois par seconde) pour le profilage à l’échelle du cluster.

• 0 pour désactiver le minuteur.

Voir aussi :

• Table système trace_log

Valeur par défaut Cloud : 3000000000.

​

queue_max_wait_ms

Temps d’attente dans la file de requêtes si le nombre de requêtes concurrentes dépasse le maximum autorisé.

​

rabbitmq_max_wait_ms

Le délai d’attente avant nouvelle tentative de lecture depuis RabbitMQ.

​

read_backoff_max_throughput

Paramètre permettant de réduire le nombre de threads en cas de lectures lentes. Les événements sont comptabilisés lorsque le débit de lecture est inférieur à ce nombre d’octets par seconde.

​

read_backoff_min_concurrency

Paramètre visant à conserver un nombre minimal de threads en cas de lectures lentes.

​

read_backoff_min_events

Paramètre permettant de réduire le nombre de threads en cas de lectures lentes. Nombre d’événements à partir duquel le nombre de threads sera réduit.

​

read_backoff_min_interval_between_events_ms

Paramètre permettant de réduire le nombre de threads en cas de lectures lentes. Ne tenez pas compte de l’événement si le précédent s’est produit il y a moins d’un certain intervalle de temps.

​

read_backoff_min_latency_ms

Paramètre permettant de réduire le nombre de threads en cas de lectures lentes. Ne tient compte que des lectures ayant pris au moins ce temps.

​

read_from_distributed_cache_if_exists_otherwise_bypass_cache

N’a d’effet que dans ClickHouse Cloud. Identique à read_from_filesystem_cache_if_exists_otherwise_bypass_cache, mais pour le cache distribué.

​

read_from_filesystem_cache_if_exists_otherwise_bypass_cache

Permet d’utiliser le cache du système de fichiers en mode passif : tirer parti des entrées de cache existantes, sans en ajouter de nouvelles. Si vous activez ce paramètre pour des requêtes ad hoc lourdes et le laissez désactivé pour des requêtes courtes en temps réel, cela permet d’éviter que des requêtes trop lourdes ne saturent le cache et d’améliorer l’efficacité globale du système.

​

read_from_page_cache_if_exists_otherwise_bypass_cache

Utiliser le cache de pages en espace utilisateur en mode passif, comme pour read_from_filesystem_cache_if_exists_otherwise_bypass_cache.

​

read_in_order_two_level_merge_threshold

Nombre minimal de parts à lire pour exécuter l’étape de fusion préliminaire lors d’une lecture multithread suivant l’ordre de la clé primaire.

​

read_in_order_use_buffering

Utilise la mise en mémoire tampon avant la fusion lors de la lecture selon l’ordre de la clé primaire. Cela augmente le parallélisme de l’exécution des requêtes

​

read_in_order_use_virtual_row

Utiliser une ligne virtuelle lors de la lecture en suivant l’ordre de la clé primaire ou d’une de ses fonctions monotones. Cela est utile lors de la recherche sur plusieurs parts, car seules les parts pertinentes sont parcourues.

​

read_in_order_use_virtual_row_per_block

Lorsque ce paramètre est activé avec read_in_order_use_virtual_row, une ligne virtuelle est émise après chaque bloc lu (et pas seulement au début de chaque part). Cela permet à MergingSortedTransform de reprioriser les sources plus fréquemment, ce qui est utile lorsque les filtres en aval écartent de nombreuses lignes et que les données sont réparties de façon inégale entre les parts. Notez que cela désactive l’optimisation read_in_order_use_buffering ainsi que la fusion préliminaire (read_in_order_two_level_merge_threshold) pour la lecture.

​

read_overflow_mode

Que faire lorsque la limite est atteinte.

​

read_overflow_mode_leaf

Définit ce qui se passe lorsque le volume de données lues dépasse l’une des limites au niveau des nœuds feuille.

Options possibles :

• throw : lever une exception (par défaut).
• break : arrêter l’exécution de la requête et renvoyer un résultat partiel.

​

priorité_de_lecture

Priorité de lecture des données depuis le système de fichiers local ou distant. Pris en charge uniquement avec la méthode ‘pread_threadpool’ pour le système de fichiers local et la méthode threadpool pour le système de fichiers distant.

​

read_through_distributed_cache

N’a d’effet que dans ClickHouse Cloud. Autorise la lecture à partir du cache distribué

​

readonly

0 - aucune restriction en mode lecture seule. 1 - uniquement les requêtes de lecture, ainsi que la modification des paramètres explicitement autorisés. 2 - uniquement les requêtes de lecture, ainsi que la modification des paramètres, à l’exception du paramètre ‘readonly’.

​

receive_data_timeout_ms

Délai d’attente de connexion pour la réception du premier paquet de données ou d’un paquet indiquant une progression positive provenant d’une réplique

​

receive_timeout

Délai d’attente de réception des données via le réseau, en secondes. Si aucun octet n’est reçu pendant cet intervalle, une exception est levée. Si vous définissez ce paramètre côté client, le send_timeout du socket sera également défini sur l’extrémité correspondante de la connexion côté serveur.

​

recursive_cte_max_steps_in_type_inference

Nombre maximal d’itérations pour inférer les types de colonnes dans les CTE récursives. Les types de colonnes sont déterminés en appliquant getLeastSupertype de manière itérative aux branches non récursive et récursive de l’UNION ALL jusqu’à convergence. Définissez cette valeur sur 0 pour désactiver l’élargissement des types et utiliser uniquement les types de la partie non récursive.

​

regexp_dict_allow_hyperscan

Autorise le dictionnaire regexp_tree à utiliser la bibliothèque Hyperscan.

​

regexp_dict_flag_case_insensitive

Utilise une correspondance insensible à la casse pour un dictionnaire regexp_tree. Ce paramètre peut être remplacé dans des expressions individuelles avec (?i) et (?-i).

​

regexp_dict_flag_dotall

Permet à « . » de correspondre aux sauts de ligne pour un dictionnaire regexp_tree.

​

regexp_max_matches_per_row

Définit le nombre maximal de correspondances d’une même expression régulière par ligne. Utilisez ce paramètre pour éviter une surcharge de mémoire lors de l’utilisation d’une expression régulière gourmande dans la fonction extractAllGroupsHorizontal.

Valeurs possibles :

• Entier positif.

​

reject_expensive_hyperscan_regexps

Rejette les motifs dont l’évaluation avec hyperscan sera probablement coûteuse (en raison d’une explosion du nombre d’états du NFA)

​

remerge_sort_lowered_memory_bytes_ratio

Si l’utilisation de la mémoire après le remerge n’est pas réduite d’au moins ce ratio, le remerge sera désactivé.

​

remote_filesystem_read_method

Méthode de lecture des données sur le système de fichiers distant, au choix : read, threadpool.

​

remote_filesystem_read_prefetch

Indique s’il faut utiliser la prélecture lors de la lecture de données depuis un système de fichiers distant.

​

remote_fs_read_backoff_max_tries

Nombre maximal de tentatives de lecture avec délai progressif

​

remote_fs_read_max_backoff_ms

Temps d’attente maximal lors d’une tentative de lecture de données depuis le disque distant

​

remote_read_min_bytes_for_seek

Nombre minimal d’octets requis pour qu’une lecture distante (URL, S3) effectue un seek plutôt qu’une lecture avec ignore.

​

rename_files_after_processing

• Type: String

• Valeur par défaut : Chaîne vide

Ce paramètre permet de spécifier un motif de renommage pour les fichiers traités par la fonction de table file. Lorsque cette option est définie, tous les fichiers lus par la fonction de table file sont renommés selon le motif indiqué avec des marqueurs de substitution, uniquement si leur traitement a réussi.

​

Espaces réservés

• %a — Nom complet du fichier d’origine (par ex. : “sample.csv”).
• %f — Nom du fichier d’origine sans extension (par ex. : “sample”).
• %e — Extension du fichier d’origine, point compris (par ex. : “.csv”).
• %t — Horodatage (en microsecondes).
• %% — Signe de pourcentage (”%”).

​

Exemple

• Option : --rename_files_after_processing="processed_%f_%t%e"

• Requête : SELECT * FROM file('sample.csv')

Si la lecture de sample.csv réussit, le fichier sera renommé processed_sample_1683473210851438.csv

​

replace_running_query

Lors de l’utilisation de l’interface HTTP, vous pouvez transmettre le paramètre ‘query_id’. Il s’agit d’une chaîne quelconque servant d’identifiant de requête. Si une requête du même utilisateur avec le même ‘query_id’ existe déjà à ce moment-là, le comportement dépend du paramètre ‘replace_running_query’.

0 (par défaut) – Lever une exception (ne pas autoriser l’exécution de la requête si une requête avec le même ‘query_id’ est déjà en cours d’exécution).

1 – Annuler l’ancienne requête et lancer la nouvelle.

Définissez ce paramètre sur 1 pour implémenter des suggestions de conditions de segmentation. Après la saisie du caractère suivant, si l’ancienne requête n’est pas encore terminée, elle doit être annulée.

​

replace_running_query_max_wait_ms

Le temps d’attente pour que la requête en cours avec le même query_id se termine, lorsque le paramètre replace_running_query est actif.

Valeurs possibles :

• Entier positif.
• 0 — Levée d’une exception qui empêche d’exécuter une nouvelle requête si le serveur exécute déjà une requête avec le même query_id.

​

replication_wait_for_inactive_replica_timeout

Indique combien de temps (en secondes) il faut attendre pour que les répliques inactives exécutent les requêtes ALTER, OPTIMIZE ou TRUNCATE.

Valeurs possibles :

• 0 — Ne pas attendre.
• Entier négatif — Attendre indéfiniment.
• Entier positif — Nombre de secondes à attendre.

​

restore_replace_external_dictionary_source_to_null

Remplace les sources de dictionnaire externes par Null lors de la restauration. Utile pour les tests

​

restore_replace_external_engines_to_null

Pour les tests. Remplace tous les moteurs externes par Null afin de ne pas établir de connexions externes.

​

restore_replace_external_table_functions_to_null

À utiliser à des fins de test. Remplace toutes les fonctions de table externes par Null afin d’éviter d’établir des connexions externes.

​

restore_replicated_merge_tree_to_shared_merge_tree

Remplace le moteur de table ReplicatedMergeTree par SharedMergeTree lors de RESTORE.

Valeur par défaut dans Cloud : 1.

​

result_overflow_mode

Valeur par défaut dans Cloud : throw

Définit ce qu’il faut faire si le volume du résultat dépasse l’une des limites.

Valeurs possibles :

• throw : lever une exception (par défaut).
• break : arrêter l’exécution de la requête et renvoyer le résultat partiel, comme si les données source étaient épuisées.

L’utilisation de ‘break’ est similaire à l’utilisation de LIMIT. Break interrompt l’exécution uniquement au niveau du bloc. Cela signifie que le nombre de lignes renvoyées est supérieur à max_result_rows, est un multiple de max_block_size et dépend de max_threads.

Exemple

Query

SET max_threads = 3, max_block_size = 3333;
SET max_result_rows = 3334, result_overflow_mode = 'break';

SELECT *
FROM numbers_mt(100000)
FORMAT Null;

Result

6666 rows in set. ...

​

rewrite_count_distinct_if_with_count_distinct_implementation

Permet de réécrire countDistcintIf à l’aide du paramètre count_distinct_implementation.

Valeurs possibles :

• true — Autoriser.
• false — Interdire.

​

rewrite_in_to_join

Réécrire des expressions du type ‘x IN subquery’ en JOIN. Cela peut être utile pour optimiser l’ensemble de la requête via le réordonnancement des jointures.

​

rows_before_aggregation

Lorsqu’il est activé, ClickHouse fournit la valeur exacte de la statistique rows_before_aggregation, qui représente le nombre de lignes lues avant l’agrégatio

​

s3_allow_multipart_copy

Autorise la copie en plusieurs parties dans S3.

​

s3_allow_parallel_part_upload

Utilise plusieurs threads pour les téléversements multipart S3. Cela peut entraîner une utilisation de la mémoire légèrement plus élevée

​

s3_check_objects_after_upload

Vérifie chaque objet téléversé vers S3 à l’aide d’une requête head afin de s’assurer que le téléversement s’est bien déroulé

​

s3_connect_timeout_ms

Délai d’expiration de la connexion à l’hôte pour les disques S3.

​

s3_create_new_file_on_insert

Active ou désactive la création d’un nouveau fichier à chaque insertion dans les tables utilisant le moteur S3. Si cette option est activée, un nouvel objet S3 est créé à chaque insertion avec la clé, selon un schéma semblable à celui-ci :

initial : data.Parquet.gz -> data.1.Parquet.gz -> data.2.Parquet.gz, etc.

Valeurs possibles :

• 0 — la requête INSERT crée un nouveau fichier, ou échoue si le fichier existe et que s3_truncate_on_insert n’est pas défini.
• 1 — la requête INSERT crée un nouveau fichier à chaque insertion en utilisant un suffixe (à partir du deuxième) si s3_truncate_on_insert n’est pas défini.

Pour plus de détails, voir ici.

​

s3_disable_checksum

N’effectue pas de somme de contrôle lors de l’envoi d’un fichier vers S3. Cela accélère les écritures en évitant des traitements excessifs sur le fichier. C’est généralement sûr, car les données des tables MergeTree sont de toute façon déjà protégées par des sommes de contrôle dans ClickHouse, et lorsque S3 est accessible via HTTPS, la couche TLS garantit déjà l’intégrité des données pendant leur transfert sur le réseau. Des sommes de contrôle supplémentaires sur S3 apportent toutefois une défense en profondeur.

​

s3_ignore_file_doesnt_exist

Ignore l’absence d’un fichier lors de la lecture de certaines clés s’il n’existe pas.

Valeurs possibles :

• 1 — SELECT renvoie un résultat vide.
• 0 — SELECT lève une exception.

​

s3_list_object_keys_size

Nombre maximal de fichiers pouvant être renvoyés par la requête ListObject en lot

​

s3_max_connections

Le nombre maximal de connexions par serveur.

​

s3_max_get_burst

Nombre maximal de requêtes pouvant être envoyées simultanément avant d’atteindre la limite de requêtes par seconde. Par défaut (0), cette valeur est égale à s3_max_get_rps

​

s3_max_get_rps

Limite du nombre de requêtes GET vers S3 par seconde avant l’activation du throttling. Zéro signifie illimité.

​

s3_max_inflight_parts_for_one_file

Le nombre maximal de parties pouvant être chargées simultanément dans une requête de téléversement multipart. 0 signifie qu’il n’y a pas de limite.

​

s3_max_part_number

Numéro maximal de part pour le téléversement vers S3.

​

s3_max_put_burst

Nombre maximal de requêtes pouvant être envoyées simultanément avant d’atteindre la limite de requêtes par seconde. Par défaut (0), est égal à s3_max_put_rps

​

s3_max_put_rps

Limite du nombre de requêtes PUT vers S3 par seconde avant l’application d’un throttling. Zéro signifie illimité.

​

s3_max_single_operation_copy_size

Taille maximale pour une copie en une seule opération dans S3. Ce paramètre n’est utilisé que si s3_allow_multipart_copy est true.

​

s3_max_single_part_upload_size

La taille maximale d’un objet à téléverser vers S3 en un seul envoi.

​

s3_max_single_read_retries

Le nombre maximal de tentatives lors d’une lecture unique depuis S3.

​

s3_max_unexpected_write_error_retries

Le nombre maximal de tentatives en cas d’erreurs inattendues lors de l’écriture dans S3.

​

s3_max_upload_part_size

La taille maximale d’une part à téléverser lors d’un téléversement multipart vers S3.

​

s3_min_upload_part_size

La taille minimale d’une partie à téléverser lors d’un téléversement multipart vers S3.

​

s3_path_filter_limit

Nombre maximal de valeurs _path pouvant être extraites des filtres de requête afin d’être utilisées pour l’itération sur les fichiers au lieu d’un parcours par motif glob. 0 signifie désactivé.

​

s3_request_timeout_ms

Délai d’inactivité maximal pour l’envoi et la réception de données vers/depuis S3. Échec si un seul appel de lecture ou d’écriture TCP reste bloqué pendant cette durée.

​

s3_skip_empty_files

Active ou désactive le fait d’ignorer les fichiers vides dans les tables du moteur S3.

Valeurs possibles :

• 0 — SELECT lève une exception si le fichier vide n’est pas compatible avec le format demandé.
• 1 — SELECT renvoie un résultat vide pour un fichier vide.

​

s3_slow_all_threads_after_network_error

Lorsque ce paramètre est défini sur true, tous les threads exécutant des requêtes S3 vers le même endpoint de sauvegarde sont ralentis dès qu’une seule requête S3 rencontre une erreur réseau pouvant donner lieu à une nouvelle tentative, comme un timeout de socket. Lorsque ce paramètre est défini sur false, chaque thread gère le délai progressif des requêtes S3 indépendamment des autres.

​

s3_strict_upload_part_size

La taille exacte de la partie à téléverser lors d’un téléversement multipart vers S3 (certaines implémentations ne prennent pas en charge les parties de taille variable).

​

s3_throw_on_zero_files_match

Déclenche une erreur lorsque la requête ListObjects ne trouve aucun fichier correspondant

​

s3_truncate_on_insert

Active ou désactive la troncature avant les insertions dans les tables utilisant le moteur S3. Si cette option est désactivée, une exception est levée lors d’une tentative d’insertion si un objet S3 existe déjà.

Valeurs possibles :

• 0 — la requête INSERT crée un nouveau fichier, ou échoue si le fichier existe et que s3_create_new_file_on_insert n’est pas défini.
• 1 — la requête INSERT remplace le contenu existant du fichier par les nouvelles données.

Voir plus de détails ici.

​

s3_upload_part_size_multiply_factor

Multiplie s3_min_upload_part_size par ce facteur chaque fois que s3_multiply_parts_count_threshold parts ont été téléversées vers S3 lors d’une seule écriture.

​

s3_upload_part_size_multiply_parts_count_threshold

Chaque fois que ce nombre de parties a été téléversé vers S3, s3_min_upload_part_size est multiplié par s3_upload_part_size_multiply_factor.

​

s3_uri_style

Impose le style de l’endpoint S3. Valeurs possibles : auto, virtual_hosted, path.

​

s3_use_adaptive_timeouts

Lorsqu’il est défini sur true, les deux premières tentatives de toutes les requêtes S3 sont effectuées avec des délais d’envoi et de réception courts. Lorsqu’il est défini sur false, toutes les tentatives sont effectuées avec les mêmes délais.

​

s3_validate_request_settings

Active la validation des paramètres de requête S3. Valeurs possibles :

• 1 — valide les paramètres.
• 0 — ne valide pas les paramètres.

​

s3queue_default_zookeeper_path

Préfixe de chemin ZooKeeper par défaut pour le moteur S3Queue

​

s3queue_enable_logging_to_s3queue_log

Active l’écriture dans system.s3queue_log. La valeur peut être redéfinie pour chaque table via les paramètres de table

​

s3queue_keeper_fault_injection_probability

Probabilité d’injection de pannes de Keeper pour S3Queue.

​

s3queue_migrate_old_metadata_to_buckets

Migrer l’ancienne structure de métadonnées de la table S3Queue vers une nouvelle structure

​

schema_inference_cache_require_modification_time_for_url

Utiliser le schéma en cache pour l’URL avec validation de la date de dernière modification (pour les URL avec l’en-tête Last-Modified)

​

schema_inference_use_cache_for_azure

Utiliser le cache pour l’inférence de schéma lors de l’utilisation de la fonction de table Azure

​

schema_inference_use_cache_for_file

Utiliser le cache dans l’inférence de schéma lors de l’utilisation de la fonction de table file

​

schema_inference_use_cache_for_hdfs

Utiliser le cache pour l’inférence de schéma lors de l’utilisation de la fonction de table hdfs

​

schema_inference_use_cache_for_s3

Utiliser le cache pour l’inférence de schéma lors de l’utilisation de la fonction de table S3

​

schema_inference_use_cache_for_url

Utilise le cache pour l’inférence de schéma lors de l’utilisation de la fonction de table url

​

secondary_indices_enable_bulk_filtering

Active l’algorithme de filtrage en bloc pour les indices. Il est supposé être systématiquement plus performant, mais ce paramètre est conservé pour des raisons de compatibilité et de contrôle.

​

select_sequential_consistency

Ce paramètre n’a pas le même comportement avec SharedMergeTree et ReplicatedMergeTree. Voir SharedMergeTree consistency pour plus d’informations sur le comportement de select_sequential_consistency dans SharedMergeTree.

Active ou désactive la cohérence séquentielle pour les requêtes SELECT. Nécessite que insert_quorum_parallel soit désactivé (il est activé par défaut).

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Utilisation

Lorsque la cohérence séquentielle est activée, ClickHouse n’autorise le client à exécuter la requête SELECT que sur les répliques qui contiennent les données de toutes les requêtes INSERT précédentes exécutées avec insert_quorum. Si le client interroge une réplique partielle, ClickHouse génère une exception. La requête SELECT n’inclura pas les données qui n’ont pas encore été écrites sur le quorum de répliques.

Lorsque insert_quorum_parallel est activé (par défaut), select_sequential_consistency ne fonctionne pas. En effet, des requêtes INSERT parallèles peuvent être écrites sur différents groupes de répliques formant le quorum, sans garantie qu’une seule réplique ait reçu toutes les écritures.

Voir aussi :

• insert_quorum
• insert_quorum_timeout
• insert_quorum_parallel

​

send_logs_level

Envoyer au client les logs texte du serveur à partir du niveau minimal spécifié. Valeurs valides : ‘trace’, ‘debug’, ‘information’, ‘warning’, ‘error’, ‘fatal’, ‘none’

​

send_logs_source_regexp

Envoyer les logs texte du serveur avec l’expression régulière spécifiée pour faire correspondre le nom de la source des logs. Si vide, toutes les sources sont prises en compte.

​

send_profile_events

Active ou désactive l’envoi de paquets ProfileEvents aux clients.

Ce paramètre peut être désactivé afin de réduire le trafic réseau pour les clients qui n’ont pas besoin des événements de profil.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

send_progress_in_http_headers

Active ou désactive les en-têtes HTTP de réponse X-ClickHouse-Progress dans les réponses de clickhouse-server.

Pour plus d’informations, consultez la description de l’interface HTTP.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

send_table_structure_on_insert_with_inline_data

S’il est désactivé et que la requête INSERT contient des données intégrées, le serveur n’enverra pas au client, via le protocole natif, la structure de la table ni les valeurs par défaut des colonnes. À la place, le serveur analysera lui-même les données intégrées. Cela peut améliorer les performances pour de nombreuses petites insertions via le protocole natif.

​

send_timeout

Délai d’expiration pour l’envoi de données sur le réseau, en secondes. Si un client doit envoyer des données mais ne parvient pas à envoyer le moindre octet pendant cet intervalle, une exception est levée. Si vous définissez ce paramètre côté client, le receive_timeout du socket sera également défini du côté correspondant de la connexion sur le serveur.

​

serialize_query_plan

Sérialise le plan de requête pour le traitement distribué

​

serialize_string_in_memory_with_zero_byte

Sérialise les valeurs String lors de l’agrégation en ajoutant un octet nul à la fin. Activez ce paramètre pour préserver la compatibilité lors de l’exécution de requêtes sur un cluster composé de versions incompatibles.

​

session_timezone

Définit le fuseau horaire implicite de la session ou de la requête actuelle. Le fuseau horaire implicite est celui appliqué aux valeurs de type DateTime/DateTime64 qui n’ont pas de fuseau horaire explicitement défini. Ce paramètre prévaut sur le fuseau horaire implicite configuré globalement (au niveau du serveur). Une valeur de ” (chaîne vide) signifie que le fuseau horaire implicite de la session ou de la requête actuelle est identique au fuseau horaire du serveur.

Vous pouvez utiliser les fonctions timeZone() et serverTimeZone() pour obtenir le fuseau horaire de la session et celui du serveur.

Valeurs possibles :

• Tout nom de fuseau horaire issu de system.time_zones, par exemple Europe/Berlin, UTC ou Zulu

Exemples :

SELECT timeZone(), serverTimeZone() FORMAT CSV

"Europe/Berlin","Europe/Berlin"

SELECT timeZone(), serverTimeZone() SETTINGS session_timezone = 'Asia/Novosibirsk' FORMAT CSV

"Asia/Novosibirsk","Europe/Berlin"

Attribuez au DateTime interne le fuseau horaire de la session ‘America/Denver’, sans spécifier explicitement de fuseau horaire :

SELECT toDateTime64(toDateTime64('1999-12-12 23:23:23.123', 3), 3, 'Europe/Zurich') SETTINGS session_timezone = 'America/Denver' FORMAT TSV

1999-12-13 07:23:23.123

Certaines fonctions qui analysent DateTime/DateTime64 ne respectent pas session_timezone. Cela peut entraîner des erreurs subtiles. Voir l’exemple et l’explication ci-dessous.

CREATE TABLE test_tz (`d` DateTime('UTC')) ENGINE = Memory AS SELECT toDateTime('2000-01-01 00:00:00', 'UTC');

SELECT *, timeZone() FROM test_tz WHERE d = toDateTime('2000-01-01 00:00:00') SETTINGS session_timezone = 'Asia/Novosibirsk'
0 rows in set.

SELECT *, timeZone() FROM test_tz WHERE d = '2000-01-01 00:00:00' SETTINGS session_timezone = 'Asia/Novosibirsk'
┌───────────────────d─┬─timeZone()───────┐
│ 2000-01-01 00:00:00 │ Asia/Novosibirsk │
└─────────────────────┴──────────────────┘

Cela est dû à des pipelines d’analyse différents :

• toDateTime(), utilisé sans fuseau horaire explicitement indiqué dans la première requête SELECT, tient compte du paramètre session_timezone et du fuseau horaire global.
• Dans la deuxième requête, une valeur DateTime est analysée à partir d’une String et hérite du type et du fuseau horaire de la colonne existante d. Par conséquent, le paramètre session_timezone et le fuseau horaire global ne sont pas pris en compte.

Voir aussi

• timezone

​

set_overflow_mode

Définit le comportement à adopter lorsque la quantité de données dépasse l’une des limites.

Valeurs possibles :

• throw : lever une exception (par défaut).
• break : arrêter l’exécution de la requête et renvoyer un résultat partiel, comme si les données source étaient épuisées.

​

shared_merge_tree_sequential_consistency_initial_parts_update_backoff_ms

Backoff initial, en millisecondes, pour la mise à jour des parts lors de l’utilisation de select_sequential_consistency avec SharedMergeTree. Disponible uniquement dans ClickHouse Cloud.

​

shared_merge_tree_sequential_consistency_max_parts_update_backoff_ms

Backoff maximal, en millisecondes, pour la mise à jour des parts lors de l’utilisation de select_sequential_consistency avec SharedMergeTree. Disponible uniquement dans ClickHouse Cloud.

​

shared_merge_tree_sequential_consistency_parts_update_max_retries

Nombre maximal de tentatives de mise à jour des parts lors de l’utilisation de select_sequential_consistency avec SharedMergeTree. Disponible uniquement dans ClickHouse Cloud.

​

shared_merge_tree_sync_parts_on_partition_operations

Synchronise automatiquement l’ensemble des parts de données après les opérations de partition MOVE|REPLACE|ATTACH dans les tables SMT. Cloud uniquement

​

short_circuit_function_evaluation

Permet d’évaluer les fonctions if, multiIf, and et or avec une évaluation en court-circuit. Cela permet d’optimiser l’exécution des expressions complexes dans ces fonctions et d’éviter d’éventuelles exceptions (comme une division par zéro lorsqu’elle n’est pas attendue).

Valeurs possibles :

• enable — Active l’évaluation en court-circuit pour les fonctions qui s’y prêtent (celles qui peuvent lever une exception ou sont coûteuses en calcul).
• force_enable — Active l’évaluation en court-circuit pour toutes les fonctions.
• disable — Désactive l’évaluation en court-circuit.

​

short_circuit_function_evaluation_for_nulls

Optimise l’évaluation des fonctions qui renvoient NULL dès qu’un argument est NULL. Lorsque le pourcentage de valeurs NULL dans les arguments de la fonction dépasse le seuil short_circuit_function_evaluation_for_nulls_threshold, le système n’évalue plus la fonction ligne par ligne. Il renvoie à la place immédiatement NULL pour toutes les lignes, ce qui évite des calculs inutiles.

​

short_circuit_function_evaluation_for_nulls_threshold

Seuil du ratio de valeurs NULL à partir duquel les fonctions avec des arguments Nullable sont exécutées uniquement sur les lignes dont tous les arguments ont des valeurs non-NULL. S’applique lorsque le paramètre short_circuit_function_evaluation_for_nulls est activé. Lorsque le ratio de lignes contenant des valeurs NULL par rapport au nombre total de lignes dépasse ce seuil, ces lignes ne seront pas évaluées.

​

show_processlist_include_internal

Afficher les processus auxiliaires internes dans le résultat de la requête SHOW PROCESSLIST.

Les processus internes comprennent les rechargements de dictionnaires, les rechargements de vues matérialisées actualisables, les SELECT auxiliaires exécutés dans les requêtes SHOW ..., les requêtes auxiliaires CREATE DATABASE ... exécutées en interne pour gérer les tables défectueuses, etc.

​

show_remote_databases_in_system_tables

Alias : show_data_lake_catalogs_in_system_tables

Active l’affichage des bases de données distantes (catalogues de data lake, MySQL, PostgreSQL) dans les tables système.

​

show_table_uuid_in_table_create_query_if_not_nil

Définit l’affichage de la requête SHOW TABLE.

Valeurs possibles :

• 0 — La requête sera affichée sans l’UUID de la table.
• 1 — La requête sera affichée avec l’UUID de la table.

​

single_join_prefer_left_table

Pour un seul JOIN, en cas d’ambiguïté de l’identifiant, privilégier la table de gauche

​

skip_redundant_aliases_in_udf

Les alias redondants ne sont pas utilisés (substitués) dans les fonctions définies par l’utilisateur afin d’en simplifier l’utilisation.

Valeurs possibles :

• 1 — Les alias sont ignorés (substitués) dans les UDF.
• 0 — Les alias ne sont pas ignorés (substitués) dans les UDF.

Exemple

Différence entre l’état activé et désactivé :

Requête :

SET skip_redundant_aliases_in_udf = 0;
CREATE FUNCTION IF NOT EXISTS test_03274 AS ( x ) -> ((x + 1 as y, y + 2));

EXPLAIN SYNTAX SELECT test_03274(4 + 2);

Résultat :

SELECT ((4 + 2) + 1 AS y, y + 2)

Requête :

SET skip_redundant_aliases_in_udf = 1;
CREATE FUNCTION IF NOT EXISTS test_03274 AS ( x ) -> ((x + 1 as y, y + 2));

EXPLAIN SYNTAX SELECT test_03274(4 + 2);

Résultat :

SELECT ((4 + 2) + 1, ((4 + 2) + 1) + 2)

​

skip_unavailable_shards

Active ou désactive l’ignorance silencieuse des shards indisponibles.

Un shard est considéré comme indisponible si toutes ses répliques sont indisponibles. Une réplique est indisponible dans les cas suivants :

• ClickHouse ne peut pas se connecter à la réplique, quelle qu’en soit la raison.

  Lors de la connexion à une réplique, ClickHouse effectue plusieurs tentatives. Si elles échouent toutes, la réplique est considérée comme indisponible.

• La réplique ne peut pas être résolue via DNS.

  Si le nom d’hôte de la réplique ne peut pas être résolu via DNS, cela peut indiquer les situations suivantes :

  • L’hôte de la réplique n’a pas d’enregistrement DNS. Cela peut se produire dans des systèmes utilisant un DNS dynamique, par exemple Kubernetes, où les nœuds peuvent être temporairement impossibles à résoudre pendant une période d’indisponibilité, sans que cela constitue une erreur.

  • Erreur de configuration. Le fichier de configuration de ClickHouse contient un nom d’hôte incorrect.

Valeurs possibles :

• 1 — ignorance activée.

  Si un shard est indisponible, ClickHouse renvoie un résultat basé sur des données partielles et ne signale pas les problèmes de disponibilité des nœuds.

• 0 — ignorance désactivée.

  Si un shard est indisponible, ClickHouse lève une exception.

​

sleep_after_receiving_query_ms

Temps d’attente après réception d’une requête dans TCPHandler

​

sleep_in_send_data_ms

Temps d’attente lors de l’envoi de données dans TCPHandler

​

sleep_in_send_tables_status_ms

Délai d’attente lors de l’envoi de la réponse de statut des tables dans TCPHandler

​

sort_overflow_mode

Définit le comportement à adopter si le nombre de lignes reçues avant le tri dépasse l’une des limites.

Valeurs possibles :

• throw : lever une exception.
• break : arrêter l’exécution de la requête et renvoyer un résultat partiel.

​

split_intersecting_parts_ranges_into_layers_final

Diviser les plages de parts chevauchantes en couches pendant l’optimisation FINAL

​

split_parts_ranges_into_intersecting_and_non_intersecting_final

Scinder les plages de parts en plages qui se chevauchent et plages qui ne se chevauchent pas lors de l’optimisation FINAL

​

splitby_max_substrings_includes_remaining_string

Contrôle si la fonction splitBy*() avec l’argument max_substrings > 0 inclut la chaîne restante dans le dernier élément du tableau résultant.

Valeurs possibles :

• 0 - La chaîne restante ne sera pas incluse dans le dernier élément du tableau résultant.
• 1 - La chaîne restante sera incluse dans le dernier élément du tableau résultant. Il s’agit du comportement de la fonction split() de Spark et de la méthode ‘string.split()’ de Python.

​

stop_refreshable_materialized_views_on_startup

Au démarrage du serveur, empêche la planification des vues matérialisées actualisables, comme avec SYSTEM STOP VIEWS. Vous pouvez ensuite les démarrer manuellement avec SYSTEM START VIEWS ou SYSTEM START VIEW <name>. S’applique également aux vues nouvellement créées. N’a aucun effet sur les vues matérialisées non actualisables.

​

storage_file_read_method

Méthode de lecture des données à partir du fichier de stockage, parmi : read, pread, mmap. La méthode mmap ne s’applique pas à clickhouse-server (elle est destinée à clickhouse-local).

​

storage_system_stack_trace_pipe_read_timeout_ms

Temps maximal de lecture depuis un pipe pour recevoir des informations des threads lors de l’interrogation de la table system.stack_trace. Ce paramètre est utilisé à des fins de test et n’est pas destiné à être modifié par les utilisateurs.

​

stream_flush_interval_ms

S’applique aux tables en streaming en cas de délai d’attente, ou lorsqu’un thread génère max_insert_block_size lignes.

La valeur par défaut est 7500.

Plus la valeur est faible, plus les données sont vidées fréquemment dans la table. Définir une valeur trop faible entraîne de mauvaises performances.

​

stream_like_engine_allow_direct_select

Autorise les requêtes SELECT directes pour les moteurs Kafka, RabbitMQ, FileLog, Redis Streams, S3Queue, AzureQueue et NATS. S’il existe des vues matérialisées attachées, la requête SELECT n’est pas autorisée, même si ce paramètre est activé. S’il n’existe pas de vues matérialisées attachées, l’activation de ce paramètre permet de lire les données. Gardez à l’esprit qu’en général, les données lues sont supprimées de la file d’attente. Pour éviter leur suppression, les paramètres du moteur concerné doivent être configurés correctement.

​

stream_like_engine_insert_queue

Lorsqu’un moteur de type stream lit à partir de plusieurs files d’attente, l’utilisateur doit en sélectionner une pour y effectuer un insert lors de l’écriture. Utilisé par Redis Streams et NATS.

​

stream_poll_timeout_ms

Délai d’expiration pour l’interrogation des données depuis/vers les stockages en streaming.

​

system_events_show_zero_values

Permet de sélectionner les événements de valeur nulle dans system.events.

Certains systèmes de supervision exigent que toutes les valeurs de métriques leur soient transmises à chaque relevé, même si la valeur de la métrique est nulle.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

Exemples

Requête

SELECT * FROM system.events WHERE event='QueryMemoryLimitExceeded';

Résultat

Ok.

Requête

SET system_events_show_zero_values = 1;
SELECT * FROM system.events WHERE event='QueryMemoryLimitExceeded';

Résultat

┌─event────────────────────┬─value─┬─description───────────────────────────────────────────┐
│ QueryMemoryLimitExceeded │     0 │ Number of times when memory limit exceeded for query. │
└──────────────────────────┴───────┴───────────────────────────────────────────────────────┘

​

system_metric_log_show_zero_values_in_histograms

Contrôle si les données d’histogramme de valeur nulle sont écrites dans la colonne imbriquée histograms de system.metric_log.

Par défaut, les histogrammes dont le count total d’observations est nul sont ignorés et, dans chaque histogramme émis, les entrées de bucket sans observation sont également omises de la map histogram. Activez ce paramètre pour écrire chaque histogramme et chaque bucket, quel que soit le count — utile pour les systèmes de monitoring qui exigent que chaque métrique apparaisse à chaque point de contrôle.

Valeurs possibles :

• 0 — Désactivé. Les histogrammes avec count = 0 ne sont pas émis ; les histogrammes émis incluent uniquement les buckets ayant reçu au moins une observation.
• 1 — Activé. Tous les histogrammes sont écrits et chaque limite de bucket apparaît dans histogram.

​

table_engine_read_through_distributed_cache

N’a d’effet que dans ClickHouse Cloud. Autorise la lecture à partir du distributed cache via les moteurs de table / fonctions de table (s3, azure, etc.)

​

table_function_remote_max_addresses

Définit le nombre maximal d’adresses générées à partir de motifs pour la fonction remote.

Valeurs possibles :

• Entier positif.

​

tcp_keep_alive_timeout

Durée, en secondes, pendant laquelle la connexion doit rester inactive avant que TCP ne commence à envoyer des sondes de keepalive

​

temporary_data_in_cache_reserve_space_wait_lock_timeout_milliseconds

Temps d’attente pour verrouiller le cache lors de la réservation d’espace pour les données temporaires dans le cache du système de fichiers

​

temporary_files_buffer_size

Taille du tampon des processus d’écriture des fichiers temporaires. Une taille de tampon plus élevée réduit le nombre d’appels système, mais augmente la consommation de mémoire.

​

temporary_files_codec

Définit le codec de compression des fichiers temporaires utilisés pour les opérations de tri et de jointure sur disque.

Valeurs possibles :

• LZ4 — La compression LZ4 est appliquée.
• NONE — Aucune compression n’est appliquée.

​

text_index_density_threshold

Seuil de densité pour la sélection de l’algorithme en mode lazy posting list. En dessous du seuil : intersection leapfrog. À partir du seuil : bitmap par force brute.

​

text_index_hint_max_selectivity

Sélectivité maximale du filtre permettant d’utiliser l’indice construit à partir de l’index de texte inversé.

​

text_index_like_max_postings_to_read

Nombre maximal de grandes listes de postings à lire lorsque l’évaluation de LIKE sur l’index de texte via le balayage du dictionnaire est activée.

Nécessite que use_text_index_like_evaluation_by_dictionary_scan soit activé.

​

text_index_like_min_pattern_length

Longueur minimale de la chaîne alphanumérique recherchée dans un motif LIKE/ILIKE, requise pour utiliser l’évaluation LIKE de l’index de texte via le balayage du dictionnaire. Les motifs plus courts que ce seuil correspondent à trop de tokens du dictionnaire et sont ignorés afin d’éviter des analyses coûteuses.

Nécessite que use_text_index_like_evaluation_by_dictionary_scan soit activé.

​

text_index_posting_list_apply_mode

Contrôle la façon dont les posting lists sont appliquées lors des requêtes sur l’index de texte. ‘materialize’ (par défaut) décode immédiatement les posting lists en Roaring Bitmaps. ‘lazy’ utilise un décodage à la demande basé sur un curseur (nécessite le format d’index V2 et allow_experimental_text_index_lazy_apply).

​

throw_if_no_data_to_insert

Autorise ou interdit les INSERTs vides. Ce paramètre est activé par défaut (une erreur est générée en cas d’insert vide). S’applique uniquement aux INSERTs effectués avec clickhouse-client ou via l’interface gRPC.

​

throw_on_error_from_cache_on_write_operations

Ignorer les erreurs du cache lors de la mise en cache pendant les opérations d’écriture (INSERT, merges)

​

throw_on_max_partitions_per_insert_block

Permet de contrôler le comportement lorsque max_partitions_per_insert_block est atteint.

Valeurs possibles :

• true - Lorsqu’un bloc d’insertion atteint max_partitions_per_insert_block, une exception est levée.
• false - Consigne un avertissement lorsque max_partitions_per_insert_block est atteint.

Cela peut être utile si vous cherchez à comprendre l’impact sur les utilisateurs lors de la modification de max_partitions_per_insert_block.

​

throw_on_unsupported_query_inside_transaction

Lever une exception si une requête non prise en charge est exécutée dans une transactio

​

timeout_before_checking_execution_speed

Vérifie que la vitesse d’exécution n’est pas trop faible (pas inférieure à min_execution_speed), une fois le délai spécifié, en secondes, écoulé.

​

timeout_overflow_mode

Définit ce qu’il faut faire si la requête s’exécute plus longtemps que max_execution_time ou si la durée d’exécution estimée dépasse max_estimated_execution_time.

Valeurs possibles :

• throw : lever une exception (par défaut).
• break : arrêter l’exécution de la requête et renvoyer le résultat partiel, comme si les données source étaient épuisées.

​

timeout_overflow_mode_leaf

Définit ce qui se produit lorsque la requête exécutée sur un nœud feuille dépasse max_execution_time_leaf.

Valeurs possibles :

• throw : déclencher une exception (par défaut).
• break : arrêter l’exécution de la requête et renvoyer un résultat partiel, comme si les données sources étaient épuisées.

​

totals_auto_threshold

Le seuil de totals_mode = 'auto'. Voir la section « modificateur WITH TOTALS ».

​

totals_mode

Comment calculer TOTALS en présence de HAVING, ainsi que de max_rows_to_group_by et de group_by_overflow_mode = ‘any’. Voir la section « modificateur WITH TOTALS ».

​

trace_profile_events

Active ou désactive la collecte de stacktraces à chaque mise à jour des événements de profil, ainsi que l’envoi dans trace_log du nom de l’événement de profil et de la valeur de l’incrément.

Valeurs possibles :

• 1 — Traçage des événements de profil activé.
• 0 — Traçage des événements de profil désactivé.

​

trace_profile_events_list

Lorsque le paramètre trace_profile_events est activé, limitez les événements tracés à la liste spécifiée de noms séparés par des virgules. Si trace_profile_events_list est une chaîne vide (par défaut), tracez tous les événements de profil.

Valeur d’exemple : ‘DiskS3ReadMicroseconds,DiskS3ReadRequestsCount,SelectQueryTimeMicroseconds,ReadBufferFromS3Bytes’

L’utilisation de ce paramètre permet de collecter plus précisément les données pour un grand nombre de requêtes, car sinon, le volume considérable d’événements peut saturer la file d’attente interne du journal système, et une partie d’entre eux sera perdue.

​

transfer_overflow_mode

Détermine ce qui se passe lorsque la quantité de données dépasse l’une des limites.

Valeurs possibles :

• throw : lever une exception (par défaut).
• break : arrêter l’exécution de la requête et renvoyer un résultat partiel, comme si la source de données était épuisée.

​

transform_null_in

Permet de considérer comme égales les valeurs NULL pour l’opérateur IN.

Par défaut, les valeurs NULL ne peuvent pas être comparées, car NULL représente une valeur indéfinie. Ainsi, la comparaison expr = NULL doit toujours renvoyer false. Avec ce paramètre, NULL = NULL renvoie true pour l’opérateur IN.

Valeurs possibles :

• 0 — La comparaison de valeurs NULL avec l’opérateur IN renvoie false.
• 1 — La comparaison de valeurs NULL avec l’opérateur IN renvoie true.

Exemple

Considérez la table null_in :

┌──idx─┬─────i─┐
│    1 │     1 │
│    2 │  NULL │
│    3 │     3 │
└──────┴───────┘

Requête :

SELECT idx, i FROM null_in WHERE i IN (1, NULL) SETTINGS transform_null_in = 0;

Résultat :

┌──idx─┬────i─┐
│    1 │    1 │
└──────┴──────┘

Requête :

SELECT idx, i FROM null_in WHERE i IN (1, NULL) SETTINGS transform_null_in = 1;

Résultat :

┌──idx─┬─────i─┐
│    1 │     1 │
│    2 │  NULL │
└──────┴───────┘

Voir aussi

• Traitement de NULL dans les opérateurs IN

​

traverse_shadow_remote_data_paths

Parcourt les données figées (répertoire shadow) en plus des données réelles de la table lors d’une requête sur system.remote_data_paths

​

union_default_mode

Définit le mode de combinaison des résultats de requêtes SELECT. Ce paramètre n’est utilisé qu’avec UNION lorsque UNION ALL ou UNION DISTINCT n’est pas explicitement indiqué.

Valeurs possibles :

• 'DISTINCT' — ClickHouse renvoie les lignes issues de la combinaison des requêtes en supprimant les doublons.
• 'ALL' — ClickHouse renvoie toutes les lignes issues de la combinaison des requêtes, y compris les doublons.
• '' — ClickHouse génère une exception lorsqu’il est utilisé avec UNION.

Voir des exemples dans UNION.

​

unique_key_max_encoded_size

Taille maximale (en octets) de l’encodage binaire préservant l’ordre d’une seule ligne UNIQUE KEY.

​

unknown_packet_in_send_data

Envoyer un paquet inconnu à la place du n-ième paquet de données

​

update_parallel_mode

Détermine le comportement des requêtes UPDATE concurrentes.

Valeurs possibles :

• sync - exécute toutes les requêtes UPDATE de manière séquentielle.
• auto - exécute de manière séquentielle uniquement les requêtes UPDATE pour lesquelles il existe des dépendances entre les colonnes mises à jour dans une requête et les colonnes utilisées dans les expressions d’une autre requête.
• async - ne synchronise pas les requêtes UPDATE.

​

update_sequential_consistency

Si la valeur est true, l’ensemble des parts est mis à jour vers la dernière version avant l’exécution de la mise à jour.

​

url_base

L’URL de base utilisée pour résoudre les URL relatives dans la fonction de table url et le moteur de table URL.

Lorsqu’elle est définie, les URL relatives sont résolues comme suit :

• URL relative au chemin (par ex. data.csv) : fusionnée avec le chemin de l’URL de base conformément à la RFC 3986. Tout ce qui suit le dernier / dans le chemin de base est remplacé par l’URL relative ; la barre oblique finale est donc importante : https://example.com/dir/ + data.csv = https://example.com/dir/data.csv, mais https://example.com/dir + data.csv = https://example.com/data.csv. Si l’URL de base n’a pas de chemin (par ex. https://example.com), un / est inséré : https://example.com/data.csv. Les segments de point (./ et ../) dans l’URL relative sont normalisés : https://example.com/dir/ + ../a.csv = https://example.com/a.csv.
• URL relative à l’hôte (par ex. /test/data.csv) : résolue à partir du schéma et de l’hôte de l’URL de base.
• URL relative au schéma (par ex. //other.com/test/data.csv) : résolue à l’aide du schéma de l’URL de base.
• Référence contenant uniquement une query string (par ex. ?x=1) : ajoutée au chemin de l’URL de base (en remplaçant toute requête ou tout fragment existant).
• Référence contenant uniquement un fragment (par ex. #frag) : ajoutée à l’URL de base, en conservant toute query string (en remplaçant tout fragment existant).
• Référence vide : renvoie l’URL de base sans fragment.

Par exemple, si url_base vaut https://example.com/def/, alors :

• data.csv est résolu en https://example.com/def/data.csv
• /test/data.csv est résolu en https://example.com/test/data.csv
• //other.com/test/data.csv est résolu en https://other.com/test/data.csv

​

use_async_executor_for_materialized_views

Utilise une exécution asynchrone, et potentiellement multithreadée, de la requête de vue matérialisée, ce qui peut accélérer le traitement des vues lors d’INSERT, mais aussi consommer davantage de mémoire.

​

use_cache_for_count_from_files

Active la mise en cache du nombre de lignes lors du comptage dans des fichiers avec les fonctions de table file/s3/url/hdfs/azureBlobStorage.

Activé par défaut.

​

use_client_time_zone

Utilise le fuseau horaire du client pour interpréter les valeurs de chaîne DateTime, au lieu d’utiliser le fuseau horaire du serveur.

​

use_compact_format_in_distributed_parts_names

Utilise le format compact pour stocker les blocks des INSERT en arrière-plan (distributed_foreground_insert) dans les tables utilisant le moteur Distributed.

Valeurs possibles :

• 0 — Utilise le format de répertoire user[:password]@host:port#default_database.
• 1 — Utilise le format de répertoire [shard{shard_index}[_replica{replica_index}]].

• avec use_compact_format_in_distributed_parts_names=0, les modifications de la définition du cluster ne seront pas appliquées aux INSERT en arrière-plan.
• avec use_compact_format_in_distributed_parts_names=1, modifier l’ordre des nœuds dans la définition du cluster changera shard_index/replica_index ; soyez donc vigilant.

​

use_concurrency_control

Tient compte du contrôle de la concurrence du serveur (voir les paramètres globaux du serveur concurrent_threads_soft_limit_num et concurrent_threads_soft_limit_ratio_to_cores). S’il est désactivé, cela permet d’utiliser un plus grand nombre de threads même si le serveur est surchargé (non recommandé en usage normal, et surtout nécessaire pour les tests).

Valeur par défaut dans Cloud : 0.

​

use_hash_table_stats_for_join_reordering

Active l’utilisation des statistiques collectées sur les tables de hachage pour estimer la cardinalité lors du réordonnancement des jointures

​

use_hedged_requests

Active le mécanisme de hedged requests pour les requêtes distantes. Cela permet d’établir plusieurs connexions vers différentes répliques pour une requête. Une nouvelle connexion est ouverte si la ou les connexions existantes avec la ou les répliques n’ont pas été établies dans le délai hedged_connection_timeout ou si aucune donnée n’a été reçue dans le délai receive_data_timeout. La requête utilise la première connexion qui envoie un paquet Progress non vide (ou un paquet Data, si allow_changing_replica_until_first_data_packet) ; les autres connexions sont annulées. Les requêtes avec max_parallel_replicas > 1 sont prises en charge.

Activé par défaut.

Valeur par défaut dans Cloud : 0.

​

use_hive_partitioning

Lorsqu’il est activé, ClickHouse détecte le partitionnement de style Hive dans le chemin (/name=value/) des moteurs de table de type fichier File/S3/URL/HDFS/AzureBlobStorage, et permet d’utiliser les colonnes de partition comme colonnes virtuelles dans la requête. Ces colonnes virtuelles auront les mêmes noms que dans le chemin partitionné, mais commenceront par _.

​

use_iceberg_metadata_files_cache

Si cette option est activée, la fonction de table Iceberg et le moteur de stockage Iceberg peuvent utiliser le cache des fichiers de métadonnées Iceberg.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

use_iceberg_partition_pruning

Utilise l’élagage des partitions pour les tables Iceberg

​

use_index_for_in_with_subqueries

Tente d’utiliser un index lorsqu’il y a une sous-requête ou une expression de table à droite de l’opérateur IN.

​

use_index_for_in_with_subqueries_max_values

Taille maximale de l’ensemble situé dans la partie droite de l’opérateur IN pour utiliser l’index de la table lors du filtrage. Cela permet d’éviter une dégradation des performances et une consommation mémoire accrue due à la préparation de structures de données supplémentaires pour les requêtes volumineuses. Zéro signifie qu’il n’y a pas de limite.

​

use_join_disjunctions_push_down

Active le pushdown vers les côtés d’entrée correspondants des parties de conditions de JOIN reliées par OR (« pushdown partiel »). Cela permet aux moteurs de stockage de filtrer plus tôt, ce qui peut réduire la quantité de données lues. L’optimisation préserve la sémantique et n’est appliquée que lorsque chaque branche OR de niveau supérieur apporte au moins un prédicat déterministe pour le côté cible.

​

use_legacy_to_time

Lorsqu’il est activé, ce paramètre permet d’utiliser l’ancienne fonction toTime, qui convertit une date avec heure en une date fixe donnée, tout en conservant l’heure. Sinon, une nouvelle fonction toTime est utilisée, qui convertit différents types de données en type Time. L’ancienne fonction legacy reste également accessible sans condition sous le nom toTimeWithFixedDate.

​

use_lightweight_primary_key_index_analysis

Optimise l’analyse de l’index de clé primaire pour les tables MergeTree avec des clés primaires longues.

Lorsqu’il est activé, la durée d’exécution de l’analyse de l’index dépend principalement de la complexité du filtre de la requête (c’est-à-dire des colonnes clés réellement utilisées), et non de la longueur de la clé primaire. Par conséquent, l’extension de la clé de tri n’ajoute qu’un surcoût négligeable à l’analyse de l’index pour les requêtes qui ne filtrent que sur quelques-unes de ses colonnes.

Valeurs possibles :

• 0 — Désactivé. Toutes les colonnes de la clé primaire sont traitées lors de l’analyse de l’index.
• 1 — Activé.

​

use_page_cache_for_disks_without_file_cache

Utilisez le cache de pages en espace utilisateur pour les disques distants sur lesquels le cache du système de fichiers n’est pas activé.

​

use_page_cache_for_local_disks

Utilise le cache de pages en espace utilisateur lors de la lecture à partir de disques locaux. Utilisé pour les tests, il est peu probable qu’il améliore réellement les performances en pratique. Nécessite local_filesystem_read_method = ‘pread’ ou ‘read’. Ne désactive pas le cache de pages du système d’exploitation ; min_bytes_to_use_direct_io peut être utilisé à cette fin. Affecte uniquement les tables ordinaires, pas la fonction de table file() ni le moteur de table File().

​

use_page_cache_for_object_storage

Utilise le cache de pages en espace utilisateur lors de la lecture depuis les fonctions de table du stockage objet (s3, azure, hdfs) et les moteurs de table (S3, Azure, HDFS).

​

use_page_cache_with_distributed_cache

Utiliser le cache de pages en espace utilisateur lorsque le distributed cache est utilisé.

​

use_paimon_partition_pruning

Utiliser l’élagage des partitions de Paimon pour les fonctions de table Paimon

​

use_parquet_metadata_cache

Lorsqu’il est activé, le format Parquet peut utiliser le cache des métadonnées Parquet.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

use_partition_pruning

Alias : use_partition_key

Utilise la clé de partition pour réduire le nombre de partitions analysées lors de l’exécution des requêtes sur les tables MergeTree.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_primary_key

Utilise la clé primaire pour élaguer les granules lors de l’exécution des requêtes sur les tables MergeTree.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_query_cache

Si cette option est activée, les requêtes SELECT peuvent utiliser le cache de requêtes. Les paramètres enable_reads_from_query_cache et enable_writes_to_query_cache contrôlent plus précisément l’utilisation du cache.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

use_query_condition_cache

Active le cache des conditions de requête. Ce cache stocke les plages de granules dans les data parts qui ne satisfont pas la condition de la clause WHERE, et réutilise ces informations comme index éphémère pour les requêtes suivantes.

Valeurs possibles :

• 0 - Désactivé
• 1 - Activé

​

use_reader_executor

Expérimental. Fait passer les lectures par le nouveau pipeline ReaderExecutor au lieu de l’empilement legacy de tampons de lecture. Revient au chemin legacy pour les configurations que l’executor ne prend pas encore en charge.

​

use_roaring_bitmap_iceberg_positional_deletes

Utiliser un bitmap roaring pour les suppressions positionnelles dans Iceberg.

​

use_skip_indexes

Utiliser les index de saut de données lors de l’exécution des requêtes.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_skip_indexes_for_disjunctions

Évalue les filtres WHERE comportant des conditions AND et OR mixtes à l’aide des skip indexes. Exemple : WHERE A = 5 AND (B = 5 OR C = 5). S’il est désactivé, les skip indexes sont toujours utilisés pour évaluer les conditions WHERE, mais celles-ci ne doivent contenir que des clauses reliées par AND.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_skip_indexes_for_top_k

Active l’utilisation des index de saut de données pour le filtrage TopK.

Lorsque ce paramètre est activé, si un index MinMax existe sur la colonne dans une requête ORDER BY <column> LIMIT n, l’optimiseur tentera d’utiliser cet index MinMax pour ignorer les granules non pertinentes pour le résultat final. Cela peut réduire la latence des requêtes.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_skip_indexes_if_final

Détermine si les index de saut sont utilisés lors de l’exécution d’une requête avec le modificateur FINAL.

Les index de saut peuvent exclure des lignes (granules) contenant les données les plus récentes, ce qui peut entraîner des résultats incorrects pour une requête avec le modificateur FINAL. Lorsque ce paramètre est activé, les index de saut sont appliqués même avec le modificateur FINAL, ce qui peut améliorer les performances, mais au risque d’omettre des mises à jour récentes. Ce paramètre doit être activé en même temps que le paramètre use_skip_indexes_if_final_exact_mode (activé par défaut).

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_skip_indexes_if_final_exact_mode

Détermine si les granules renvoyés par un skip index sont étendus dans les parts les plus récentes afin de garantir des résultats corrects lors de l’exécution d’une requête avec le modificateur FINAL.

L’utilisation de skip indexes peut exclure des lignes (granules) contenant les données les plus récentes, ce qui peut entraîner des résultats incorrects. Ce paramètre permet de garantir des résultats corrects en analysant les parts les plus récentes qui chevauchent les plages renvoyées par le skip index. Ce paramètre ne doit être désactivé que si des résultats approximatifs basés sur la consultation du skip index conviennent à l’application.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_skip_indexes_on_data_read

Active l’utilisation des index de saut de données pendant la lecture des données.

Lorsque cette option est activée, les index de saut sont évalués dynamiquement au moment de la lecture de chaque granule de données, plutôt que d’être analysés à l’avance avant le début de l’exécution de la requête. Cela peut réduire la latence au démarrage de la requête.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_statistics

/// à préférer à ‘allow_statistics_optimize’ pour rester cohérent avec ‘use_primary_key’ et ‘use_skip_indexes’ Permet d’utiliser les statistiques pour optimiser les requêtes

​

use_statistics_cache

Utiliser le cache de statistiques dans une requête pour éviter la surcharge liée au chargement des statistiques pour chaque part

​

use_statistics_for_part_pruning

Utilise des statistiques pour filtrer les parts pendant l’exécution des requêtes.

Lorsqu’il est activé, l’élagage dans les requêtes SELECT utilise les statistiques de colonnes (par ex. les statistiques MinMax) pour éliminer, avant toute lecture de données, les parts qui ne peuvent pas contenir les données recherchées.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_strict_insert_block_limits

Lorsqu’il est activé, ce paramètre applique strictement les limites minimale et maximale de taille des blocs d’insertion.

Un bloc est émis lorsque :

• Seuils min (AND) : min_insert_block_size_rows ET min_insert_block_size_bytes sont tous deux atteints.
• Seuils max (OR) : soit max_insert_block_size_rows, soit max_insert_block_size_bytes est atteint.

Lorsqu’il est désactivé, un bloc est émis lorsque :

• Seuils min (OR) : min_insert_block_size_rows OU min_insert_block_size_bytes est atteint.

Remarque : si les paramètres max sont inférieurs aux paramètres min, les limites max priment et les blocs seront émis avant que les seuils min ne soient atteints.

Remarque : ce paramètre est automatiquement désactivé pour les insertions asynchrones, car celles-ci attachent des tokens de déduplication par entrée incompatibles avec le fractionnement des blocs nécessaire à l’application stricte de ces limites.

Désactivé par défaut.

​

use_structure_from_insertion_table_in_table_functions

Utilise la structure de la table d’insertion au lieu de l’inférence de schéma à partir des données. Valeurs possibles : 0 - désactivé, 1 - activé, 2 - auto

​

use_text_index_header_cache

Indique s’il faut utiliser un cache de l’en-tête désérialisé de l’index de texte. L’utilisation du cache de l’en-tête de l’index de texte peut réduire considérablement la latence et augmenter le débit lors du traitement d’un grand nombre de requêtes sur l’index de texte.

​

use_text_index_like_evaluation_by_dictionary_scan

Permet d’évaluer les requêtes LIKE/ILIKE en analysant le dictionnaire de l’index de texte inversé.

​

use_text_index_postings_cache

Indique s’il faut utiliser un cache des listes de postings désérialisées de l’index de texte. L’utilisation du cache des listes de postings de l’index de texte peut réduire considérablement la latence et augmenter le débit lors de l’exécution d’un grand nombre de requêtes sur l’index de texte.

​

use_text_index_tokens_cache

Indique s’il faut utiliser un cache d’informations désérialisées sur les jetons de l’index de texte. L’utilisation du cache des jetons de l’index de texte peut réduire considérablement la latence et augmenter le débit lors de l’exécution d’un grand nombre de requêtes sur l’index de texte.

​

use_top_k_dynamic_filtering

Active l’optimisation du filtrage dynamique lors de l’exécution d’une requête ORDER BY <column> LIMIT n.

Lorsqu’elle est activée, le moteur d’exécution de la requête tente d’ignorer les granules et les lignes qui ne feront pas partie des top N lignes finales du jeu de résultats. Cette optimisation est de nature dynamique, et les gains de latence dépendent de la distribution des données et de la présence d’autres prédicats dans la requête.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_top_k_dynamic_filtering_for_variable_length_types

Permet à use_top_k_dynamic_filtering de s’appliquer lorsque la colonne de tri a un type de données de longueur variable (par ex. String, Array, Map, Tuple contenant des éléments de longueur variable).

Pour de tels types, la comparaison du seuil ligne par ligne effectuée par le filtre dynamique peut coûter plus qu’elle ne rapporte lorsque le minimum lexicographique de la colonne prédomine (par ex. des chaînes majoritairement vides) et que peu de granules peuvent être ignorés. Dans ce cas, le filtre dynamique dégrade la latence des requêtes au lieu de l’améliorer.

Lorsque ce paramètre vaut 0, le filtrage dynamique est limité aux colonnes dont les valeurs ont une taille maximale fixe en mémoire (nombres, Date, DateTime, FixedString, Enum, Nullable de tels types, Tuple de tels types). Lorsqu’il vaut 1, le filtrage dynamique s’applique aussi aux types de longueur variable.

Valeurs possibles :

• 0 — Désactivé.
• 1 — Activé.

​

use_uncompressed_cache

Indique s’il faut utiliser un cache de blocs non compressés. Accepte 0 ou 1. Par défaut : 0 (désactivé). L’utilisation du cache non compressé (uniquement pour les tables de la famille MergeTree) peut réduire considérablement la latence et augmenter le débit lors du traitement d’un grand nombre de requêtes courtes. Activez ce paramètre pour les utilisateurs qui envoient fréquemment de courtes requêtes. Tenez également compte du paramètre de configuration uncompressed_cache_size (défini uniquement dans le fichier de configuration), qui correspond à la taille des blocs du cache non compressé. Par défaut, elle est de 8 GiB. Le cache non compressé se remplit selon les besoins, et les données les moins utilisées sont automatiquement supprimées.

Pour les requêtes qui lisent un volume de données au moins relativement important (un million de lignes ou plus), le cache non compressé est désactivé automatiquement afin de réserver l’espace aux requêtes réellement petites. Cela signifie que vous pouvez laisser le paramètre ‘use_uncompressed_cache’ toujours défini sur 1.

​

use_variant_as_common_type

Permet d’utiliser le type Variant comme type de résultat pour les fonctions if/multiIf/array/map lorsqu’il n’existe aucun type commun entre les types d’arguments.

Exemple :

SET use_variant_as_common_type = 1;
SELECT toTypeName(if(number % 2, number, range(number))) as variant_type FROM numbers(1);
SELECT if(number % 2, number, range(number)) as variant FROM numbers(5);

┌─variant_type───────────────────┐
│ Variant(Array(UInt64), UInt64) │
└────────────────────────────────┘
┌─variant───┐
│ []        │
│ 1         │
│ [0,1]     │
│ 3         │
│ [0,1,2,3] │
└───────────┘

SET use_variant_as_common_type = 1;
SELECT toTypeName(multiIf((number % 4) = 0, 42, (number % 4) = 1, [1, 2, 3], (number % 4) = 2, 'Hello, World!', NULL)) AS variant_type FROM numbers(1);
SELECT multiIf((number % 4) = 0, 42, (number % 4) = 1, [1, 2, 3], (number % 4) = 2, 'Hello, World!', NULL) AS variant FROM numbers(4);

─variant_type─────────────────────────┐
│ Variant(Array(UInt8), String, UInt8) │
└──────────────────────────────────────┘

┌─variant───────┐
│ 42            │
│ [1,2,3]       │
│ Hello, World! │
│ ᴺᵁᴸᴸ          │
└───────────────┘

SET use_variant_as_common_type = 1;
SELECT toTypeName(array(range(number), number, 'str_' || toString(number))) as array_of_variants_type from numbers(1);
SELECT array(range(number), number, 'str_' || toString(number)) as array_of_variants FROM numbers(3);

┌─array_of_variants_type────────────────────────┐
│ Array(Variant(Array(UInt64), String, UInt64)) │
└───────────────────────────────────────────────┘

┌─array_of_variants─┐
│ [[],0,'str_0']    │
│ [[0],1,'str_1']   │
│ [[0,1],2,'str_2'] │
└───────────────────┘

SET use_variant_as_common_type = 1;
SELECT toTypeName(map('a', range(number), 'b', number, 'c', 'str_' || toString(number))) as map_of_variants_type from numbers(1);
SELECT map('a', range(number), 'b', number, 'c', 'str_' || toString(number)) as map_of_variants FROM numbers(3);

┌─map_of_variants_type────────────────────────────────┐
│ Map(String, Variant(Array(UInt64), String, UInt64)) │
└─────────────────────────────────────────────────────┘

┌─map_of_variants───────────────┐
│ {'a':[],'b':0,'c':'str_0'}    │
│ {'a':[0],'b':1,'c':'str_1'}   │
│ {'a':[0,1],'b':2,'c':'str_2'} │
└───────────────────────────────┘

​

use_variant_default_implementation_for_comparisons

Active ou désactive l’implémentation par défaut pour le type Variant dans les fonctions de comparaison.

​

use_with_fill_by_sorting_prefix

Les colonnes qui précèdent les colonnes WITH FILL dans la clause ORDER BY constituent le préfixe de tri. Les lignes ayant des valeurs différentes dans ce préfixe de tri sont remplies indépendamment

​

validate_enum_literals_in_operators

Si cette option est activée, les littéraux d’enum utilisés dans des opérateurs tels que IN, NOT IN, ==, != sont validés par rapport au type enum, et une exception est levée si le littéral ne correspond pas à une valeur enum valide.

​

validate_mutation_query

Valider les requêtes de mutation avant de les accepter. Les mutations sont exécutées en arrière-plan, et l’exécution d’une requête non valide peut les bloquer, ce qui nécessite une intervention manuelle.

Ne modifiez ce paramètre que si vous rencontrez un bogue de rupture de rétrocompatibilité.

​

validate_polygons

Active ou désactive le déclenchement d’une exception dans la fonction pointInPolygon si le polygone s’auto-intersecte ou est auto-tangent.

Valeurs possibles :

• 0 — Le déclenchement d’une exception est désactivé. pointInPolygon accepte les polygones invalides et peut renvoyer des résultats incorrects.
• 1 — Le déclenchement d’une exception est activé.

​

variant_throw_on_type_mismatch

Lorsqu’une fonction est appliquée à une colonne Variant à l’aide de l’implémentation par défaut, ce paramètre contrôle ce qui se passe pour les lignes dont le type réel est incompatible avec la fonction :

• true (par défaut) — génère une exception.
• false — renvoie NULL pour ces lignes à la place.

​

vector_search_filter_strategy

Si une requête de recherche vectorielle comporte une clause WHERE, ce paramètre détermine si elle est évaluée en premier (pre-filtering) ou si l’index de similarité vectorielle est consulté en premier (post-filtrage). Valeurs possibles :

• ‘auto’ - Postfiltering (la sémantique exacte peut changer à l’avenir).
• ‘postfilter’ - Utilise l’index de similarité vectorielle pour identifier les plus proches voisins, puis applique les autres filtres
• ‘prefilter’ - Évalue d’abord les autres filtres, puis effectue une recherche brute-force pour identifier les voisins.

​

vector_search_index_fetch_multiplier

Alias : vector_search_postfilter_multiplier

Multiplie par cette valeur le nombre de plus proches voisins récupérés depuis l’index de similarité vectorielle. S’applique uniquement lors d’un post-filtrage avec d’autres prédicats ou si le paramètre ‘vector_search_with_rescoring = 1’.

​

vector_search_with_rescoring

Indique si ClickHouse effectue un rescoring pour les requêtes qui utilisent l’index de similarité vectorielle. Sans rescoring, l’index de similarité vectorielle renvoie directement les lignes contenant les meilleures correspondances. Avec rescoring, les lignes sont extrapolées au niveau de la granule et toutes les lignes de cette granule sont à nouveau vérifiées. Dans la plupart des cas, le rescoring n’améliore la précision qu’à la marge, mais dégrade significativement les performances des requêtes de recherche vectorielle. Remarque : une requête exécutée sans rescoring, avec les répliques parallèles activées, peut basculer automatiquement vers le rescoring.

​

wait_changes_become_visible_after_commit_mode

Attendre que les modifications validées deviennent réellement visibles dans l’instantané le plus récent

​

wait_for_async_insert

Si true, attend la fin du traitement de l’insertion asynchrone

​

wait_for_async_insert_timeout

Délai d’attente du traitement de l’insertion asynchrone

​

wait_for_part_commit_in_dependent_materialized_views

Contrôle si chaque sink valide la part qu’il vient d’écrire avant que sa propre cascade de vues matérialisées dépendantes ne s’exécute, afin qu’une cascade qui relit depuis la source via JOIN voie la part écrite par ce sink.

La garantie s’applique à chaque instance de sink individuellement — les parts écrites par d’autres threads de sink du même INSERT peuvent ne pas encore être visibles. Ce paramètre ne garantit pas d’ordre de validation entre les threads.

N’a aucun effet sur les insertions dans des tables sans vues matérialisées dépendantes.

​

wait_for_window_view_fire_signal_timeout

Délai d’attente du signal de déclenchement de la window view en traitement par temps d’événement

​

webassembly_udf_max_fuel

Limite de fuel par exécution d’une instance de WebAssembly UDF. Chaque instruction WebAssembly consomme une certaine quantité de fuel. La valeur est multipliée par 1024 avant d’être transmise à l’environnement d’exécution, donc webassembly_udf_max_fuel = 1 correspond à environ 1024 unités de fuel. Définissez-la sur 0 pour supprimer toute limite finie. S’applique uniquement aux fonctions dont le paramètre propre à la fonction webassembly_udf_enable_fuel est défini sur true, ce qui est la valeur par défaut.

​

webassembly_udf_max_input_block_size

Nombre maximal de lignes transmises à une UDF WebAssembly dans un même bloc. Définissez cette valeur sur 0 pour traiter toutes les lignes en une seule fois.

​

webassembly_udf_max_instances

Nombre maximal d’instances WebAssembly UDF pouvant s’exécuter en parallèle pour chaque fonction.

​

webassembly_udf_max_memory

Limite de mémoire en octets pour chaque instance de WebAssembly UDF.

​

window_view_clean_interval

L’intervalle de nettoyage de la window view, en secondes, pour supprimer les données obsolètes.

​

window_view_heartbeat_interval

L’intervalle du signal de pulsation, en secondes, indiquant que la requête watch est active.

​

charge de travail

Nom de la charge de travail utilisée pour accéder aux ressources

​

write_full_path_in_iceberg_metadata

Écrire les chemins complets (y compris s3://) dans les fichiers de métadonnées Iceberg.

​

write_through_distributed_cache

N’a d’effet que dans ClickHouse Cloud. Autorise l’écriture dans le cache distribué (l’écriture vers S3 sera également effectuée par le cache distribué)

​

write_through_distributed_cache_buffer_size

N’a d’effet que dans ClickHouse Cloud. Définit la taille du tampon du cache distribué en écriture directe. Si la valeur est 0, utilise la taille de tampon qui aurait été utilisée en l’absence de cache distribué.

​

zstd_window_log_max

Permet de sélectionner le log de fenêtre maximal de ZSTD (il ne sera pas utilisé pour la famille MergeTree)