Essas configurações estão disponíveis em system.settings e são geradas automaticamente a partir do código-fonte.
Número máximo de linhas no Set usado na otimização lazy FINAL. Se esse limite for excedido, volta para o FINAL normal.
O número máximo de linhas distintas ao usar DISTINCT.
Limita o número de linhas na estrutura de dados do lado direito (normalmente uma
tabela hash) usada em junções de tabelas.
Essa configuração se aplica a operações SELECT … JOIN
e ao motor de tabela Join.
Se uma consulta contiver várias junções, o ClickHouse verifica essa configuração para cada
resultado intermediário. Quando o limite é atingido, a ação depende do
join_algorithm escolhido — consulte
essa configuração para ver o comportamento de cada algoritmo (spill, reparticionamento, alternância ou
throw/break, conforme join_overflow_mode).
Valores possíveis:
- Inteiro positivo.
0 — Número ilimitado de linhas.
O número máximo de linhas de um Set de dados na cláusula IN criado a partir de uma subconsulta.
max_rows_in_set_to_optimize_join
Tamanho máximo do Set para filtrar, antes da junção, as tabelas envolvidas pelos conjuntos de linhas umas das outras.
Valores possíveis:
- 0 — Desabilita.
- Qualquer inteiro positivo.
O número máximo de chaves únicas recebidas da agregação. Essa configuração permite
limitar o consumo de memória durante a agregação.
Se a agregação durante o GROUP BY gerar mais do que o número especificado de
linhas (chaves GROUP BY únicas), o comportamento será determinado por
‘group_by_overflow_mode’, que por padrão é throw, mas também pode ser alterado
para um modo aproximado de GROUP BY.
O número máximo de linhas que podem ser lidas de uma tabela ao executar uma consulta.
A restrição é verificada para cada fragmento de dados processado, aplicada apenas à
expressão de tabela mais profunda e, ao ler de um servidor remoto, verificada apenas no
servidor remoto.
O número máximo de linhas que podem ser lidas de uma tabela local em um nó folha ao
executar uma consulta distribuída. Embora consultas distribuídas possam emitir várias subconsultas
para cada shard (folha), esse limite será verificado apenas na etapa de leitura nos
nós folha e ignorado na etapa de mesclagem dos resultados no nó raiz.
Por exemplo, um cluster consiste em 2 shards, e cada shard contém uma tabela com
100 linhas. A consulta distribuída que deve ler todos os dados de ambas as
tabelas com a configuração max_rows_to_read=150 falhará, pois haverá
200 linhas no total. Uma consulta com max_rows_to_read_leaf=150 será bem-sucedida, já que os nós folha
lerão no máximo 100 linhas.
A restrição é verificada para cada fragmento de dados processado.
Essa configuração é instável com prefer_localhost_replica=1.
O número máximo de linhas antes da ordenação. Isso permite limitar o consumo de memória durante a ordenação.
Se for necessário processar mais registros do que a quantidade especificada para a operação ORDER BY,
o comportamento será determinado por sort_overflow_mode, que por padrão está definido como throw.
Número máximo de linhas que podem ser passadas para um servidor remoto ou salvas em uma
tabela temporária quando a seção GLOBAL IN/JOIN é executada.