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

​
optimize_trivial_approximate_count_query

Utilise une valeur approximative pour optimiser les requêtes de comptage triviales sur les stockages 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_trivial_count_with_sparsity_filter

Étend l’optimisation optimize_trivial_count_query aux requêtes de la forme SELECT count() FROM t WHERE col <op> const, où <op> const répartit exactement les lignes entre les valeurs par défaut et les valeurs non par défaut de col. Le décompte est alors obtenu à partir des compteurs num_defaults / num_rows par colonne que MergeTree conserve déjà dans serialization.json, sans parcours des données. Motifs reconnus :
  • col = default(col) / col != default(col) pour Int* / UInt*, String / FixedString, Date / DateTime / DateTime64, Decimal*, UUID, IPv4 / IPv6.
  • IS NULL / IS NOT NULL sur les colonnes Nullable.
  • empty(col) / notEmpty(col) sur les colonnes String.
  • col = true / col != true sur les colonnes Bool.
  • col > 0, col >= 1, col < 1, col <= 0 sur les colonnes d’entiers non signés.
  • col / NOT col seuls sur les colonnes Int*, UInt*, Bool (test de vérité).
Les motifs d’égalité ne s’appliquent pas à Float*, Enum*, Nullable, LowCardinality, ni aux types composés (Tuple, Array, Map, …) — pour ceux-ci, le décompte suit le chemin de parcours normal. Pour prendre effet, le compteur num_defaults par part doit être exact. Activez le paramètre de table MergeTree compute_exact_num_defaults_for_sparse_columns sur la table cible avant les insertions et les fusions. Les parts écrites sans ce paramètre sont silencieusement exclues de la réécriture, donc activer uniquement optimize_trivial_count_with_sparsity_filter ne suffit pas. Pour les motifs IS NULL / IS NOT NULL sur les colonnes Nullable, la colonne doit aussi avoir une entrée num_defaults dans serialization.json, ce qui n’arrive que lorsque le paramètre de table MergeTree nullable_serialization_version est défini sur allow_sparse au moment de l’insert / merge. Avec la valeur par défaut basic, les colonnes Nullable n’obtiennent aucune entrée par colonne, donc l’optimisation ne s’applique tout simplement pas. Valeurs possibles :
  • 0 — Optimisation désactivée.
    • 1 — Optimisation activée.
Voir aussi :

​
optimize_trivial_group_by_limit_query

Active ou désactive l’optimisation d’une requête triviale SELECT ... FROM table GROUP BY key_expr LIMIT n (sans clauses HAVING/ORDER BY/QUALIFY/LIMIT BY/DISTINCT/de fenêtre ni modificateurs GROUP BY) en limitant l’agrégation à n + offset clés distinctes. Si la projection ne contient aucune fonction d’agrégation, cette limite est appliquée en définissant max_rows_to_group_by = n + offset avec group_by_overflow_mode = 'any' (ce mécanisme s’applique également aux requêtes distribuées partitionnées). Si la projection contient des fonctions d’agrégation, la limite n’est appliquée que lorsque le serveur effectue l’intégralité de l’agrégation localement : dès qu’un thread d’agrégation la dépasse, tous les threads sont restreints à un même ensemble de n + offset clés conservées, ce qui garantit l’exactitude des valeurs agrégées pour les clés renvoyées. L’optimisation n’est pas appliquée lorsque l’utilisateur a explicitement défini group_by_overflow_mode sur une valeur autre que any (afin de préserver le comportement throw/break choisi), lorsqu’il a déjà défini une limite max_rows_to_group_by plus stricte, ou lorsque exact_rows_before_limit est activé (la limite conduirait rows_before_limit_at_least à indiquer au plus n + offset). Pour les requêtes dont la projection contient des fonctions d’agrégation, cette optimisation et le tas top-K de GROUP BY fourni par enable_group_by_top_k_optimization sont mutuellement exclusifs. Le tas étant plus rapide, cette limite n’est appliquée que lorsque le tas ne peut pas être utilisé : s’il est désactivé, si n + offset dépasse query_plan_max_limit_for_top_k_optimization, si max_rows_to_group_by est défini ou si le plan de requête est sérialisé. 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’ Associez ce paramètre à une valeur explicite du paramètre max_insert_threads : l’optimisation limite le SELECT à max_insert_threads threads de lecture, ce qui modifie le nombre de blocs produits par le SELECT.

​
optimize_trivial_view_pushdown_to_distributed

Lorsqu’elle est activée, pour les vues sur des tables Distributed dont la liste SELECT ne contient que des références à des colonnes, *, ou des expressions (mais aucune fonction fenêtre ni sous-requête scalaire), et qui ne comportent ni agrégation, ni regroupement, ni tri, ni jointure, l’intégralité de la requête externe est transmise à chaque segment. Cela permet à chaque segment d’appliquer localement les filtres et les expressions de la vue, réduisant ainsi la quantité de données transférées sur le réseau. Valeurs possibles :
  • 0 — L’optimisation est désactivée ; les vues sur des tables Distributed sont toujours exécutées sur le coordinateur.
  • 1 — L’optimisation est activée.