> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# paramètres de session min_*

> Paramètres de session de ClickHouse dans le groupe généré min_*.

export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
  return <div className="not-prose" style={{
    display: "flex",
    flexWrap: "wrap",
    alignItems: "baseline",
    columnGap: "0.5rem",
    rowGap: "0.125rem",
    margin: "0.375rem 0",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <div style={{
    fontWeight: 600,
    opacity: 0.72
  }}>Type</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>Par défaut</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Modifiable sans redémarrage
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Ces paramètres sont disponibles dans [system.settings](/docs/fr/reference/system-tables/settings) et sont auto-générés à partir de la [source](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp).

<div id="min_chunk_bytes_for_parallel_parsing">
  ## min\_chunk\_bytes\_for\_parallel\_parsing
</div>

<SettingsInfoBlock type="NonZeroUInt64" default_value="10485760" />

* Type : entier non signé
* Valeur par défaut : 1 MiB

La taille minimale, en octets, du fragment que chaque thread analysera en parallèle.

<div id="min_compress_block_size">
  ## min\_compress\_block\_size
</div>

<SettingsInfoBlock type="UInt64" default_value="65536" />

Pour les tables [MergeTree](/docs/fr/reference/engines/table-engines/mergetree-family/mergetree). Afin de réduire la latence lors du traitement des requêtes, un bloc est compressé à l’écriture de la mark suivante 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 pas inférieure à cette valeur ni au volume de données d’une mark.

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 32 Ko de données. Comme min\_compress\_block\_size = 65 536, un bloc compressé sera formé toutes les deux marks.

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 c’est supérieur à 65 536, un bloc compressé sera formé pour chaque mark. Dans ce cas, lors de la lecture des données sur le disque dans la plage d’une seule mark, aucune donnée supplémentaire ne sera décompressée.

<Note>
  Il s’agit d’un paramètre réservé aux experts, et vous ne devriez pas le modifier si vous débutez avec ClickHouse.
</Note>

<div id="min_filtered_ratio_for_lazy_final">
  ## min\_filtered\_ratio\_for\_lazy\_final
</div>

<SettingsInfoBlock type="Float" default_value="0.5" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "26.4"},{"label": "0.5"},{"label": "Nouveau paramètre pour le ratio minimal de marks filtrés requis pour que l’optimisation lazy de FINAL s’applique"}]}]} />

Ratio minimal de marks filtrés par l’analyse des index pour l’optimisation lazy de FINAL. Si la proportion de marks filtrés est inférieure à ce seuil, le système revient à FINAL ordinaire. La valeur 0 désactive cette vérification.

<div id="min_hit_rate_to_use_consecutive_keys_optimization">
  ## min\_hit\_rate\_to\_use\_consecutive\_keys\_optimization
</div>

<SettingsInfoBlock type="Float" default_value="0.5" />

Taux de réussite minimal d’un cache utilisé pour l’optimisation des clés consécutives dans l’agrégation, afin qu’elle reste activée

<div id="min_os_cpu_wait_time_ratio_to_throw">
  ## min\_os\_cpu\_wait\_time\_ratio\_to\_throw
</div>

<SettingsInfoBlock type="Float" default_value="0" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.5"},{"label": "0"},{"label": "Les valeurs du paramètre ont été modifiées et rétroportées dans la version 25.4"}]}, {"id": "row-2","items": [{"label": "25.4"},{"label": "0"},{"label": "Nouveau paramètre"}]}]} />

Rapport minimal entre les temps d’attente du CPU au niveau de l’OS (métrique `OSCPUWaitMicroseconds`) et les temps d’activité (métrique `OSCPUVirtualTimeMicroseconds`) à partir duquel le rejet de requêtes est envisagé. Une interpolation linéaire entre le rapport minimal et le rapport maximal est utilisée pour calculer la probabilité ; à ce niveau, cette probabilité est de 0.

<div id="min_outstreams_per_resize_after_split">
  ## min\_outstreams\_per\_resize\_after\_split
</div>

<SettingsInfoBlock type="UInt64" default_value="24" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.6"},{"label": "24"},{"label": "Nouveau paramètre."}]}]} />

Définit le nombre minimal de flux de sortie d’un processeur `Resize` ou `StrictResize` après l’exécution de la division lors de la génération du pipeline. Si le nombre de flux résultant est inférieur à cette valeur, l’opération de division n’est pas effectuée.

<div id="what-is-a-resize-node">
  ### Qu’est-ce qu’un nœud Resize
</div>

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 diviser un seul flux en plusieurs flux. À l’inverse, il peut fusionner plusieurs flux en un plus petit nombre de flux afin de regrouper le traitement des données.

Le nœud `Resize` garantit une répartition homogène 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.

<div id="why-the-resize-node-needs-to-be-split">
  ### Pourquoi le nœud Resize doit être divisé
</div>

Lors de l’exécution du pipeline, `ExecutingGraph::Node::status_mutex` du nœud `Resize`, au centre du regroupement, est fortement sujet à la contention, en particulier dans les environnements comportant un grand nombre de cœurs, et cette contention entraîne :

1. Une augmentation de la latence de `ExecutingGraph::updateNode`, ce qui affecte directement les performances des requêtes.
2. Un nombre excessif de cycles CPU est gaspillé dans la contention sur le spin-lock (`native_queued_spin_lock_slowpath`), ce qui réduit l’efficacité.
3. Une baisse de l’utilisation du CPU, ce qui limite le parallélisme et le débit.

<div id="how-the-resize-node-gets-split">
  ### Comment le nœud Resize est divisé
</div>

1. Le nombre de flux de sortie est vérifié afin de s'assurer que la division peut être effectuée : les flux de sortie de chaque processeur issu de la division 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 de flux d'entrée et de sortie.
3. Chaque groupe est traité indépendamment, ce qui réduit la contention sur les verrous.

<div id="splitting-resize-node-with-arbitrary-inputsoutputs">
  ### Division d’un nœud Resize avec des entrées/sorties quelconques
</div>

Dans certains cas, lorsque le nombre d’entrées/sorties n’est pas divisible par le nombre de nœuds `Resize` après division, certaines entrées sont reliées à des `NullSource` et certaines sorties à des `NullSink`. Cela permet d’effectuer la division sans perturber le flux global des données.

<div id="purpose-of-the-setting">
  ### Rôle du paramètre
</div>

Le paramètre `min_outstreams_per_resize_after_split` garantit que la division des nœuds `Resize` est judicieuse et évite de créer un nombre trop faible de flux, ce qui pourrait entraîner un traitement parallèle inefficace. En imposant un nombre minimal de flux de sortie, ce paramètre aide à maintenir un équilibre entre parallélisme et surcoût, optimisant ainsi l’exécution des requêtes dans les scénarios impliquant la division et la fusion de flux.

<div id="disabling-the-setting">
  ### Désactivation du paramètre
</div>

Pour désactiver la division des nœuds `Resize`, définissez ce paramètre sur 0. Cela empêche la division des nœuds `Resize` lors de la génération du pipeline, ce qui leur permet de conserver leur structure d'origine sans être divisés en nœuds plus petits.

<div id="min_table_rows_to_use_projection_index">
  ## min\_table\_rows\_to\_use\_projection\_index
</div>

<SettingsInfoBlock type="UInt64" default_value="1000000" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.11"},{"label": "1000000"},{"label": "Nouveau paramètre"}]}]} />

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.