Skip to main content
Estos ajustes están disponibles en system.settings y se generan automáticamente a partir del código fuente.

​
min_chunk_bytes_for_parallel_parsing

  • Tipo: entero sin signo
  • Valor predeterminado: 1 MiB
El tamaño mínimo del fragmento, en bytes, que cada hilo analizará en paralelo.

​
min_compress_block_size

Para las tablas MergeTree. Para reducir la latencia al procesar consultas, un bloque se comprime al escribir la siguiente marca si su tamaño es, como mínimo, min_compress_block_size. El valor predeterminado es 65.536. El tamaño real del bloque, si los datos sin comprimir son menores que max_compress_block_size, no será inferior a este valor ni al volumen de datos de una marca. Veamos un ejemplo. Supongamos que index_granularity se estableció en 8192 durante la creación de la tabla. Estamos escribiendo una columna de tipo UInt32 (4 bytes por valor). Al escribir 8192 filas, el total será de 32 KB de datos. Como min_compress_block_size = 65.536, se formará un bloque comprimido por cada dos marcas. Estamos escribiendo una columna URL de tipo String (con un tamaño medio de 60 bytes por valor). Al escribir 8192 filas, la media será de algo menos de 500 KB de datos. Como esto supera 65.536, se formará un bloque comprimido para cada marca. En este caso, al leer datos del disco en el rango de una sola marca, no se descomprimirán datos adicionales.
Esta es una configuración de nivel experto, y no deberías cambiarla si estás empezando con ClickHouse.

​
min_filtered_ratio_for_lazy_final

Proporción mínima de marcas filtradas mediante el análisis de índices para la optimización FINAL diferida. Si se filtra menos de esta fracción de marcas, se recurre al FINAL normal. El valor 0 desactiva esta comprobación.

​
min_hit_rate_to_use_consecutive_keys_optimization

Tasa mínima de aciertos de la caché usada en la optimización de claves consecutivas en la agregación para que siga habilitada

​
min_os_cpu_wait_time_ratio_to_throw

Proporción mínima entre los tiempos de espera de CPU del SO (métrica OSCPUWaitMicroseconds) y de actividad (métrica OSCPUVirtualTimeMicroseconds) a partir de la cual se considera rechazar consultas. Se usa interpolación lineal entre la proporción mínima y la máxima para calcular la probabilidad; en este punto, la probabilidad es 0.

​
min_outstreams_per_resize_after_split

Especifica el número mínimo de flujos de salida de un procesador Resize o StrictResize tras realizar la división durante la generación del pipeline. Si el número de flujos resultante es inferior a este valor, la operación de división no se llevará a cabo.

​
Qué es un nodo Resize

Un nodo Resize es un procesador del pipeline de consulta que ajusta la cantidad de flujos de datos que pasan por el pipeline. Puede aumentar o reducir el número de flujos para equilibrar la carga de trabajo entre varios hilos o procesadores. Por ejemplo, si una consulta requiere más paralelismo, el nodo Resize puede dividir un único flujo en varios flujos. A la inversa, puede combinar varios flujos en menos flujos para consolidar el procesamiento de datos. El nodo Resize garantiza que los datos se distribuyan de forma uniforme entre los flujos, manteniendo la estructura de los bloques de datos. Esto ayuda a optimizar la utilización de recursos y a mejorar el rendimiento de las consultas.

​
Por qué es necesario dividir el nodo Resize

Durante la ejecución del pipeline, ExecutingGraph::Node::status_mutex del nodo Resize, que actúa como concentrador central, presenta una contención elevada, especialmente en entornos con un gran número de núcleos, y esta contención provoca:
  1. Un aumento de la latencia de ExecutingGraph::updateNode, lo que afecta directamente al rendimiento de las consultas.
  2. Se desperdician demasiados ciclos de CPU en la contención del spin-lock (native_queued_spin_lock_slowpath), lo que reduce la eficiencia.
  3. Una menor utilización de la CPU, lo que limita el paralelismo y el rendimiento.

​
Cómo se divide el nodo Resize

  1. Se comprueba el número de flujos de salida para garantizar que la división pueda realizarse: los flujos de salida de cada procesador dividido cumplen o superan el umbral min_outstreams_per_resize_after_split.
  2. El nodo Resize se divide en nodos Resize más pequeños con el mismo número de puertos, y cada uno maneja un subconjunto de flujos de entrada y de salida.
  3. Cada grupo se procesa de forma independiente, lo que reduce la contención por bloqueos.

​
División de un nodo Resize con entradas/salidas arbitrarias

En algunos casos, cuando el número de entradas/salidas no es divisible entre el número de nodos Resize divididos, algunas entradas se conectan a NullSources y algunas salidas se conectan a NullSinks. Esto permite realizar la división sin afectar al flujo general de datos.

​
Propósito de la configuración

La configuración min_outstreams_per_resize_after_split garantiza que la división de los nodos Resize sea útil y evita crear muy pocos flujos, lo que podría dar lugar a un procesamiento en paralelo ineficiente. Al imponer un número mínimo de flujos de salida, esta configuración ayuda a mantener un equilibrio entre el paralelismo y la sobrecarga, optimizando la ejecución de consultas en escenarios que implican la división y fusión de flujos.

​
Desactivar esta configuración

Para desactivar la división de los nodos Resize, establezca esta configuración en 0. Esto evita que los nodos Resize se dividan durante la generación del pipeline, lo que les permite conservar su estructura original sin subdividirse en nodos más pequeños.

​
min_table_rows_to_use_projection_index

Si el número estimado de filas que se leerán de la tabla es mayor o igual que este umbral, ClickHouse intentará usar el índice de proyección durante la ejecución de consultas.
Última modificación el 23 de julio de 2026