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

​
apply_deleted_mask

Active le filtrage des lignes supprimées à l’aide de lightweight DELETE. 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 »

​
apply_mutations_on_fly

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

​
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 pouvant avoir des valeurs différentes d’une ligne dupliquée à l’autre, 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 : PREWHERE est également différé, indépendamment de ce paramètre, chaque fois qu’une politique de ligne est différée par apply_row_policy_after_final, car la politique de ligne doit être appliquée avant PREWHERE. C’est le cas lorsque l’expression de la politique est non déterministe, lit une colonne qui ne figure pas dans l’ORDER BY, ou lit une colonne de l’ORDER BY dont le type est un type à virgule flottante ou en contient un. Valeurs possibles :
  • 0 — PREWHERE est appliqué avant FINAL, sauf si une politique de ligne différée entraîne également son report (par défaut).
  • 1 — PREWHERE est appliqué après FINAL.

​
apply_row_policy_after_final

Lorsqu’il est activé, les politiques de ligne sont appliquées après le traitement FINAL pour les tables *MergeTree. (En particulier pour ReplacingMergeTree) Lorsque la politique est ainsi différée, PREWHERE est différé avec elle, de sorte que la politique reste appliquée en premier (voir apply_prewhere_after_final pour différer PREWHERE de manière inconditionnelle). 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 est déterministe et dépend uniquement de colonnes de ORDER BY qui ne sont pas à virgule flottante, elle sera tout de même appliquée avant FINAL par optimisation, car un tel filtrage ne peut pas affecter le résultat de la déduplication. Les colonnes à virgule flottante ou contenant des valeurs à virgule flottante (telles que Tuple(Float64, ...), Array(Float64), Nullable(Float64), etc.) sont exclues, car -0.0 et 0.0 sont dédupliquées comme une seule et même clé, alors qu’une condition de politique peut les distinguer. Valeurs possibles :
  • 0 — La politique de ligne est appliquée avant FINAL.
  • 1 — La politique de ligne est appliquée après FINAL (par défaut).

​
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 de INSERT et le formatage du résultat de la requête. La majeure partie de l’exécution des requêtes a lieu 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). Côté 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 côté client, pour une meilleure ergonomie.

​
apply_string_filters_during_scan

Pousse (pushdown) les conditions de recherche de sous-chaînes sur les colonnes de type String depuis PREWHERE vers le parcours de colonne. Lorsqu’une condition PREWHERE contient un terme de conjonction qui recherche une sous-chaîne non vide dans une colonne String (ou Nullable(String)) (LIKE, position, startsWith, endsWith ou égalité avec une chaîne non vide), le lecteur évalue chaque valeur par rapport à cette condition pendant la désérialisation et lit les valeurs qui ne correspondent pas comme des chaînes vides. La lecture est ainsi plus rapide et la consommation de mémoire réduite lorsque la condition est sélective, car les données des valeurs non correspondantes ne sont pas copiées dans la colonne. Le résultat de la requête reste inchangé, car les lignes contenant des valeurs non correspondantes sont nécessairement éliminées par PREWHERE, et de telles conditions ne correspondent jamais à une chaîne vide. Le filtre est désactivé de manière adaptative lors de l’exécution s’il s’avère peu sélectif. Permet également à l’optimisation qui déplace les conditions de WHERE vers PREWHERE de déplacer les conditions de recherche de sous-chaînes (LIKE, position, startsWith, endsWith) même lorsqu’elles portent sur toutes les colonnes interrogées (ce qui est normalement inutile, mais avec ce paramètre, le parcours lui-même devient moins coûteux). Pour cette raison, l’égalité avec une chaîne constante n’est pas déplacée : elle reste appliquée pendant le parcours lorsqu’elle figure déjà dans PREWHERE. Pris en charge pour la lecture depuis les tables MergeTree et depuis le format Parquet. Notez que l’estimation des octets en entrée, collectée pour la décision automatique concernant les répliques parallèles (RuntimeDataflowStatisticsInputBytes), repose sur la taille en mémoire des blocs lus ; elle sous-estime donc la quantité de données lues sur le disque lorsque les valeurs sont remplacées par des chaînes vides. Valeurs possibles :
  • 0 — Désactivé.
  • 1 — Activé.