configurações de sessão max_insert_*

Essas configurações estão disponíveis em system.settings e são geradas automaticamente a partir do código-fonte.

Aliases: max_insert_block_size_rows

O tamanho máximo dos blocos (em número de linhas) a serem formados para inserção em uma tabela.

Essa configuração controla a formação de blocos em dois contextos:

1. Análise de formatos: Quando o servidor analisa formatos de entrada baseados em linhas (CSV, TSV, JSONEachRow etc.) de qualquer interface (HTTP, clickhouse-client com dados inline, gRPC, PostgreSQL wire protocol), os blocos são emitidos quando:

   • Ambos min_insert_block_size_rows AND min_insert_block_size_bytes são atingidos, OR
   • max_insert_block_size_rows OR max_insert_block_size_bytes é atingido

   Observação: Ao usar clickhouse-client ou clickhouse-local para ler de um arquivo, o próprio cliente analisa os dados, e essa configuração se aplica no lado do cliente.

2. Operações de INSERT: Durante consultas INSERT e quando os dados fluem por visões materializadas, o comportamento dessa configuração depende de use_strict_insert_block_limits:

   • Quando ativado: Os blocos são emitidos quando:

     • Limiares mínimos (AND): Ambos min_insert_block_size_rows AND min_insert_block_size_bytes são atingidos
     • Limiares máximos (OR): max_insert_block_size_rows OR max_insert_block_size_bytes é atingido

   • Quando desativado: Os blocos são emitidos quando min_insert_block_size_rows OR min_insert_block_size_bytes é atingido. As configurações max_insert_block_size não são aplicadas.

Valores possíveis:

• Inteiro positivo.

O tamanho máximo dos blocos (em bytes) a serem formados para inserção em uma tabela.

Essa configuração funciona em conjunto com max_insert_block_size_rows e controla a formação de blocos no mesmo contexto. Consulte max_insert_block_size_rows para obter informações detalhadas sobre quando e como essas configurações são aplicadas.

Valores possíveis:

• Inteiro positivo.
• 0 — a configuração não participa da formação de blocos.

O número máximo de fluxos (colunas) cujo flush final da parte pode ser atrasado. Padrão: auto (100 caso o armazenamento subjacente ofereça suporte à gravação paralela, por exemplo S3, e desabilitado caso contrário)

Valor padrão no Cloud: 50.

O número máximo de threads para executar a consulta INSERT.

Isso se aplica tanto a INSERT SELECT quanto a um INSERT simples cujos dados são enviados pelo clickhouse-client ou pela interface HTTP. O lado de gravação do pipeline (agregação dos blocos e gravação na tabela de destino) é paralelizado em até essa quantidade de threads.

Valores possíveis:

• 0 — Automático. Usa o número de núcleos de CPU disponíveis no servidor (o mesmo valor automático de max_threads), reduzido sob pressão de memória por max_insert_threads_min_free_memory_per_thread.
• 1 — o INSERT é executado em uma única thread (sem execução em paralelo). Use isto para preservar a ordem de inserção de INSERT ... SELECT.
• Inteiro positivo maior que 1 — Execução em paralelo com o número especificado de threads.

Antes da versão 26.8, o padrão era 1 (sem execução em paralelo). Desde a 26.8, o padrão (0) corresponde ao número de núcleos de CPU, portanto o INSERT é paralelizado por padrão. Defina max_insert_threads como 1 (ou use a configuração compatibility) para restaurar o comportamento anterior.

Valor padrão no Cloud:

• 1 para nós com 8 GiB de memória
• 2 para nós com 16 GiB de memória
• 4 para nós maiores

O INSERT SELECT paralelo só tem efeito se a parte SELECT for executada em paralelo; consulte a configuração max_threads. Para um INSERT simples, os dados de entrada são lidos e analisados como um único fluxo, e o pipeline é então redimensionado para essa quantidade de fluxos para gravação. A paralelização do lado de gravação se aplica apenas a INSERTs simples síncronos: inserções assíncronas (async_insert = 1) são armazenadas em uma fila e gravadas em segundo plano, portanto não são afetadas por essa configuração e sempre permanecem em um único fluxo. O lado de gravação é paralelizado apenas quando é seguro fazê-lo; caso contrário, permanece em um único fluxo e esta configuração não tem efeito sobre ele. Em particular, a gravação é mantida em um único fluxo quando use_strict_insert_block_limits está habilitada, uma tabela de destino (ou uma tabela para a qual ela encaminha dados) desduplica blocos inseridos e a desduplicação de inserção está habilitada para a consulta (consulte deduplicate_insert), quando o destino tem visões materializadas dependentes — incluindo visões de uma tabela para a qual o destino encaminha dados, por exemplo, por trás de um Alias — (a menos que parallel_view_processing esteja habilitada e as cadeias de visões dependentes não apresentem riscos de desduplicação — a desduplicação nas visões está desabilitada (deduplicate_blocks_in_dependent_materialized_views) ou nenhum caminho de visão dependente possa desduplicar), e sempre para destinos Buffer e Distributed. Um Buffer grava em seu próprio contexto e um Distributed encaminha a gravação para um fragmento remoto (que pode armazenar os dados em buffer), portanto as configurações de desduplicação desta consulta não controlam a gravação final, que é mantida em um único fluxo independentemente delas. Uma inserção de quorum não paralela (insert_quorum é 2 ou maior, ou 'auto', e insert_quorum_parallel está desabilitada) também permanece em um único fluxo, pois permite apenas uma parte de quorum em andamento por tabela. Valores mais altos resultam em maior uso de memória.

Igual a max_threads_min_free_memory_per_thread, mas aplicado a max_insert_threads em vez de max_threads. O valor padrão é mais alto porque pipelines de inserção normalmente mantêm buffers maiores por thread (partes da MergeTree, blocos de compressão) do que pipelines de leitura.

Se a quantidade de memória livre for menor que max_insert_threads multiplicado por esse valor, max_insert_threads será reduzido para se ajustar, até o mínimo de 1.

Defina como 0 para desabilitar esse limite.