apply_deleted_mask
Permite filtrar las filas eliminadas con DELETE de eliminación ligera. Si se deshabilita, una consulta podrá leer esas filas. Esto resulta útil para tareas de depuración y para escenarios de “deshacer la eliminación”.apply_mutations_on_fly
Si se establece en true, las mutaciones (UPDATE y DELETE) que no estén materializadas en la parte de datos se aplicarán en las consultas SELECT.apply_prewhere_after_final
Cuando se habilita, las condiciones PREWHERE se aplican después del procesamiento FINAL en ReplacingMergeTree y motores similares. Esto puede ser útil cuando PREWHERE hace referencia a columnas que pueden tener valores distintos entre filas duplicadas y quiere que FINAL seleccione la fila que prevalece antes de filtrar. Cuando está deshabilitada, PREWHERE se aplica durante la lectura. Nota: PREWHERE también se aplaza, independientemente de esta configuración, siempre queapply_row_policy_after_final aplace una ROW POLICY,
ya que la ROW POLICY debe aplicarse antes de PREWHERE. Esto ocurre cuando la
expresión de la política no es determinista, lee una columna que no está en ORDER BY o lee una columna de ORDER BY
cuyo tipo es o contiene un tipo de coma flotante.
Valores posibles:
- 0 — PREWHERE se aplica antes de FINAL, salvo que una ROW POLICY aplazada también lo aplace (predeterminado).
- 1 — PREWHERE se aplica después de FINAL.
apply_row_policy_after_final
Cuando está habilitado, las ROW POLICY se aplican después del procesamiento de FINAL en las tablas *MergeTree. (Especialmente en ReplacingMergeTree) Cuando la política se aplaza de esta forma, PREWHERE también se aplaza para que la política se siga aplicando primero (consulteapply_prewhere_after_final para aplazar PREWHERE de forma incondicional).
Cuando está deshabilitado, las ROW POLICY se aplican antes de FINAL, lo que puede dar resultados diferentes cuando la política
filtra filas que deberían usarse para la deduplicación en ReplacingMergeTree o motores similares.
Si la expresión de la ROW POLICY es determinista y depende solo de columnas de ORDER BY que no son de coma flotante, se seguirá
aplicando antes de FINAL como optimización, ya que ese filtrado no puede afectar al resultado de la deduplicación. Las columnas de coma flotante
o las columnas que contienen valores de coma flotante (como Tuple(Float64, ...), Array(Float64), Nullable(Float64), etc.)
se excluyen porque -0.0 y 0.0 se deduplican como una sola clave, mientras que una condición de la política sí puede distinguirlos.
Valores posibles:
- 0 — La ROW POLICY se aplica antes de FINAL.
- 1 — La ROW POLICY se aplica después de FINAL (predeterminado).
apply_settings_from_server
Si el client debe aceptar la configuración del servidor. Esto solo afecta a las operaciones realizadas del lado del client, en particular el análisis de los datos de entrada de INSERT y el formato del resultado de la consulta. La mayor parte de la ejecución de consultas ocurre en el servidor y no se ve afectada por esta configuración. Normalmente, esta configuración debe establecerse en el perfil de usuario (users.xml o consultas comoALTER USER), no a través del client (argumentos de línea de comandos del client, consulta SET o sección SETTINGS de la consulta SELECT). A través del client puede cambiarse a false, pero no puede cambiarse a true (porque el servidor no enviará la configuración si el perfil de usuario tiene apply_settings_from_server = false).
Tenga en cuenta que, inicialmente (24.12), existía una configuración del servidor (send_settings_to_client), pero posteriormente fue sustituida por esta configuración de cliente para mejorar la usabilidad.
apply_string_filters_during_scan
Hace pushdown de las condiciones de búsqueda de subcadenas en columnasString desde PREWHERE hacia el escaneo de columnas.
Cuando una condición PREWHERE contiene un término conjuntivo que busca una subcadena no vacía en una columna String (o Nullable(String))
(LIKE, position, startsWith, endsWith o igualdad con una cadena no vacía), el lector evalúa cada valor con esta condición
durante la deserialización y lee como cadenas vacías los valores que no coinciden. Esto acelera la lectura y reduce el uso de memoria cuando la condición
es selectiva, ya que los datos de los valores que no coinciden no se copian en la columna. El resultado de la consulta no varía,
porque está garantizado que PREWHERE descarta las filas con valores que no coinciden y que dichas condiciones nunca coinciden con una cadena vacía.
El filtro se desactiva de forma adaptativa en tiempo de ejecución si resulta ser poco selectivo.
Además, permite que la optimización de WHERE a PREWHERE mueva las condiciones de búsqueda de subcadenas (LIKE, position, startsWith, endsWith)
incluso cuando utilizan todas las columnas consultadas (normalmente no tendría sentido, pero con esta configuración el propio escaneo resulta más económico).
La igualdad con una cadena constante no se mueve por este motivo: se sigue aplicando durante el escaneo cuando ya está en PREWHERE.
Compatible con la lectura de tablas MergeTree y del formato Parquet.
Tenga en cuenta que la estimación de los bytes de entrada que se recopila para decidir automáticamente sobre el uso de réplicas paralelas
(RuntimeDataflowStatisticsInputBytes) se basa en el tamaño en memoria de los bloques leídos, por lo que subestima
la cantidad de datos leídos del disco cuando los valores se sustituyen por cadenas vacías.
Valores posibles:
- 0 — Desactivado.
- 1 — Activado.