Skip to main content
Essas configurações estão disponíveis em system.settings e são autogeradas a partir do código-fonte.

​
apply_deleted_mask

Habilita a filtragem de linhas excluídas com exclusão leve. Se estiver desabilitado, uma consulta poderá ler essas linhas. Isso é útil para depuração e cenários de “desfazer exclusão”

​
apply_mutations_on_fly

Se true, as mutações (UPDATEs e DELETEs) que não estão materializadas na data part serão aplicadas nas instruções SELECT.

​
apply_prewhere_after_final

Quando habilitada, as condições PREWHERE são aplicadas após o processamento FINAL para ReplacingMergeTree e motores semelhantes. Isso pode ser útil quando PREWHERE faz referência a colunas que podem ter valores diferentes em linhas duplicadas e você quer que FINAL selecione a linha que prevalece antes da filtragem. Quando desabilitada, PREWHERE é aplicada durante a leitura. Observação: independentemente desta configuração, PREWHERE também é adiada sempre que uma política de linha é adiada por apply_row_policy_after_final, pois a política de linha deve ser aplicada antes de PREWHERE. Isso acontece quando a expressão da política é não determinística, lê uma coluna que não está em ORDER BY ou lê uma coluna de ORDER BY cujo tipo é ou contém um tipo de ponto flutuante. Valores possíveis:
  • 0 — PREWHERE é aplicada antes de FINAL, a menos que uma política de linha adiada também a adie (padrão).
  • 1 — PREWHERE é aplicada após FINAL.

​
apply_row_policy_after_final

Quando habilitado, as políticas de linha são aplicadas após o processamento de FINAL para tabelas *MergeTree. (Especialmente para ReplacingMergeTree) Quando a política é adiada dessa forma, PREWHERE também é adiado, para que a política continue sendo aplicada primeiro (consulte apply_prewhere_after_final para adiar PREWHERE incondicionalmente). Quando desabilitado, as políticas de linha são aplicadas antes de FINAL, o que pode causar resultados diferentes quando a política filtra linhas que deveriam ser usadas para desduplicação em ReplacingMergeTree ou motores semelhantes. Se a expressão da política de linha for determinística e depender apenas de colunas que não sejam de ponto flutuante em ORDER BY, ela ainda será aplicada antes de FINAL como uma otimização, pois essa filtragem não pode afetar o resultado da desduplicação. Colunas de ponto flutuante ou colunas que contêm valores de ponto flutuante (como Tuple(Float64, ...), Array(Float64), Nullable(Float64) etc.) são excluídas porque -0.0 e 0.0 são desduplicados como uma única chave, enquanto uma condição da política pode diferenciá-los. Valores possíveis:
  • 0 — A política de linha é aplicada antes de FINAL.
  • 1 — A política de linha é aplicada após FINAL (padrão).

​
apply_settings_from_server

Define se o cliente deve aceitar configurações do servidor. Isso afeta apenas operações executadas do lado do cliente, em particular a análise dos dados de entrada de INSERT e a formatação do resultado da consulta. A maior parte da execução da consulta acontece no servidor e não é afetada por esta configuração. Normalmente, esta configuração deve ser definida no profile do usuário (users.xml ou consultas como ALTER USER), e não por meio do cliente (argumentos de linha de comando do cliente, consulta SET ou seção SETTINGS da consulta SELECT). Pelo cliente, ela pode ser alterada para false, mas não para true (porque o servidor não enviará as configurações se o profile do usuário tiver apply_settings_from_server = false). Observe que, inicialmente (24.12), havia uma configuração do servidor (send_settings_to_client), mas depois ela foi substituída por esta configuração do cliente, para melhorar a usabilidade.

​
apply_string_filters_during_scan

Faz o pushdown de condições de busca de substring em colunas String do PREWHERE para a varredura da coluna. Quando uma condição PREWHERE contém um termo conjuntivo que busca uma substring não vazia em uma coluna String (ou Nullable(String)) (LIKE, position, startsWith, endsWith ou igualdade com uma string não vazia), o leitor verifica cada valor em relação a essa condição durante a desserialização e lê os valores que não correspondem como strings vazias. Isso torna a leitura mais rápida e reduz o uso de memória quando a condição é seletiva, pois os dados dos valores que não correspondem não são copiados para a coluna. O resultado da consulta não se altera, pois é garantido que as linhas com valores que não correspondem serão filtradas pelo PREWHERE, e essas condições nunca correspondem a uma string vazia. O filtro é desabilitado de forma adaptativa em tempo de execução caso se mostre pouco seletivo. Também permite que a otimização de WHERE para PREWHERE mova condições de busca de substring (LIKE, position, startsWith, endsWith) mesmo quando elas usam todas as colunas consultadas (normalmente isso seria inútil, mas com esta configuração a própria varredura fica mais barata). A igualdade com uma string constante não é movida por esse motivo, mas continua sendo aplicada durante a varredura quando já está no PREWHERE. Compatível com a leitura de tabelas MergeTree e do formato Parquet. Observe que a estimativa de bytes de entrada coletada para a decisão automática sobre réplicas paralelas (RuntimeDataflowStatisticsInputBytes) se baseia no tamanho em memória dos blocos lidos e, portanto, subestima a quantidade de dados lidos do disco quando os valores são substituídos por strings vazias. Valores possíveis:
  • 0 — Desabilitado.
  • 1 — Habilitado.