> ## 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.

# configurações de sessão min_*

> Configurações de sessão do ClickHouse no grupo gerado 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
  }}>Tipo</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>Padrão</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Pode ser alterado sem reiniciar
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Essas configurações estão disponíveis em [system.settings](/docs/pt-BR/reference/system-tables/settings) e são geradas automaticamente a partir do [código-fonte](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" />

* Tipo: inteiro sem sinal
* Valor padrão: 1 MiB

O tamanho mínimo do fragmento, em bytes, que cada thread analisará em paralelo.

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

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

Para tabelas [MergeTree](/docs/pt-BR/reference/engines/table-engines/mergetree-family/mergetree). Para reduzir a latência no processamento de consultas, um bloco é comprimido ao gravar a próxima marca se o tamanho dele for pelo menos `min_compress_block_size`. O padrão é 65.536.

O tamanho real do bloco, se os dados não comprimidos forem menores que `max_compress_block_size`, não será inferior a esse valor nem ao volume de dados de uma marca.

Vejamos um exemplo. Suponha que `index_granularity` tenha sido definido como 8192 durante a criação da tabela.

Estamos gravando uma coluna do tipo UInt32 (4 bytes por valor). Ao gravar 8192 linhas, o total será de 32 KB de dados. Como min\_compress\_block\_size = 65.536, um bloco comprimido será formado a cada duas marcas.

Estamos gravando uma coluna de URL do tipo String (tamanho médio de 60 bytes por valor). Ao gravar 8192 linhas, a média será de pouco menos de 500 KB de dados. Como isso é maior que 65.536, um bloco comprimido será formado para cada marca. Nesse caso, ao ler dados do disco no intervalo de uma única marca, dados extras não serão descomprimidos.

<Note>
  Esta é uma configuração de nível especialista, e você não deve alterá-la se estiver apenas começando a usar o 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": "Nova configuração para a razão mínima de marcas filtradas necessária para que a otimização FINAL lazy prossiga"}]}]} />

Razão mínima de marcas filtradas pela análise de índice para a otimização FINAL lazy. Se menos que essa fração de marcas for filtrada, o sistema recorre ao FINAL normal. O valor 0 desabilita essa verificação.

<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" />

Taxa mínima de acertos de um cache usada na otimização de chaves consecutivas na agregação para mantê-la ativada

<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": "Os valores da configuração foram alterados e receberam backport para a 25.4"}]}, {"id": "row-2","items": [{"label": "25.4"},{"label": "0"},{"label": "Nova configuração"}]}]} />

Razão mínima entre os tempos de espera da CPU do SO (métrica OSCPUWaitMicroseconds) e de atividade (métrica OSCPUVirtualTimeMicroseconds) para considerar a rejeição de consultas. A interpolação linear entre a razão mínima e a máxima é usada para calcular a probabilidade; nesse ponto, a probabilidade é 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": "Nova configuração."}]}]} />

Especifica o número mínimo de streams de saída de um processador `Resize` ou `StrictResize` após a divisão ser realizada durante a geração do pipeline. Se o número resultante de streams for menor que esse valor, a operação de divisão não será realizada.

<div id="what-is-a-resize-node">
  ### O que é um nó Resize
</div>

Um nó `Resize` é um processador no pipeline de consulta que ajusta o número de stream de dados que passam pelo pipeline. Ele pode aumentar ou diminuir o número de stream para equilibrar a carga de trabalho entre vários threads ou processadores. Por exemplo, se uma consulta exigir mais paralelismo, o nó `Resize` pode dividir um único stream em vários stream. Por outro lado, ele pode mesclar vários stream em menos stream para consolidar o processamento de dados.

O nó `Resize` garante que os dados sejam distribuídos uniformemente entre os stream, mantendo a estrutura dos blocos de dados. Isso ajuda a otimizar a utilização de recursos e a melhorar o desempenho da consulta.

<div id="why-the-resize-node-needs-to-be-split">
  ### Por que o nó Resize precisa ser dividido
</div>

Durante a execução do pipeline, o `status_mutex` de ExecutingGraph::Node no nó `Resize`, que funciona como ponto central, sofre forte contenção, especialmente em ambientes com muitos núcleos, e isso leva a:

1. Aumento da latência de ExecutingGraph::updateNode, impactando diretamente o desempenho da consulta.
2. Ciclos excessivos de CPU são desperdiçados com contenção de spin-lock (`native_queued_spin_lock_slowpath`), reduzindo a eficiência.
3. Redução da utilização da CPU, limitando o paralelismo e a taxa de transferência.

<div id="how-the-resize-node-gets-split">
  ### Como o nó Resize é dividido
</div>

1. O número de streams de saída é verificado para garantir que a divisão possa ser realizada: os streams de saída de cada processador resultante da divisão atendem ou excedem o limite `min_outstreams_per_resize_after_split`.
2. O nó `Resize` é dividido em nós `Resize` menores, com a mesma quantidade de portas, cada um lidando com um subconjunto de streams de entrada e de saída.
3. Cada grupo é processado de forma independente, reduzindo a contenção de lock.

<div id="splitting-resize-node-with-arbitrary-inputsoutputs">
  ### Divisão do nó Resize com entradas/saídas arbitrárias
</div>

Em alguns casos, quando as entradas/saídas não são divisíveis pelo número de nós `Resize` após a divisão, algumas entradas são conectadas a `NullSource`s e algumas saídas são conectadas a `NullSink`s. Isso permite que a divisão ocorra sem afetar o fluxo geral de dados.

<div id="purpose-of-the-setting">
  ### Finalidade da configuração
</div>

A configuração `min_outstreams_per_resize_after_split` garante que a divisão de nós `Resize` seja realmente útil e evita a criação de um número muito pequeno de streams, o que poderia levar a um processamento paralelo ineficiente. Ao impor um número mínimo de streams de saída, essa configuração ajuda a manter o equilíbrio entre paralelismo e sobrecarga, otimizando a execução de consultas em cenários que envolvem divisão e mesclagem de streams.

<div id="disabling-the-setting">
  ### Desativando a configuração
</div>

Para desativar a divisão de nós `Resize`, defina esta configuração como 0. Isso impedirá a divisão de nós `Resize` durante a geração do pipeline, permitindo que mantenham sua estrutura original sem serem divididos em nós menores.

<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": "Nova configuração"}]}]} />

Se o número estimado de linhas a serem lidas na tabela for maior ou igual a esse limite, o ClickHouse tentará usar o índice de projeção durante a execução da consulta.