max_avg_part_size_for_too_many_parts
La comprobación de «demasiadas partes» según ‘parts_to_delay_insert’ y ‘parts_to_throw_insert’ estará activa solo si el tamaño promedio de la parte (en la partición correspondiente) no supera el umbral especificado. Si lo supera, los INSERTs no se retrasarán ni se rechazarán. Esto permite tener cientos de terabytes en una sola tabla en un solo servidor si las partes se fusionan correctamente en partes más grandes. Esto no afecta a los umbrales de las partes inactivas ni al número total de partes.max_buckets_in_map
El número máximo de buckets para la serialización deMap. Funciona con la serialización with_buckets de Map.
El número real de buckets se determina mediante map_buckets_strategy.
El valor máximo permitido es 256.
max_cleanup_delay_period
Período máximo para limpiar registros antiguos de la cola, hash de bloques y partes.max_compress_block_size
El tamaño máximo de los bloques de datos sin comprimir antes de comprimirlos para escribirlos en una tabla. También puede especificar esta configuración en la configuración global (consulte la configuración max_compress_block_size ). El valor especificado al crear la tabla sobrescribe el valor global de esta configuración.max_concurrent_queries
Número máximo de consultas ejecutadas de forma concurrente relacionadas con la tabla MergeTree. Las consultas seguirán estando limitadas por otros ajustes demax_concurrent_queries.
Valores posibles:
- Entero positivo.
0— Sin límite.
0 (sin límite).
Ejemplo
max_digestion_size_per_segment
Configuración obsoleta; no tiene ningún efecto.max_file_name_length
La longitud máxima del nombre de archivo para conservarlo tal cual, sin aplicar hash. Solo tiene efecto si la configuraciónreplace_long_file_name_to_hash está habilitada.
El valor de esta configuración no incluye la longitud de la extensión del archivo. Por lo tanto,
se recomienda establecerlo por debajo de la longitud máxima del nombre de archivo (normalmente 255
bytes), dejando cierto margen para evitar errores del sistema de archivos.
max_partitions_to_read
Limita el número máximo de particiones a las que se puede acceder en una sola consulta. El valor de esta configuración especificado al crear la tabla puede sobrescribirse mediante una configuración a nivel de consulta. Posibles valores:- Cualquier número entero positivo.
max_projections
El número máximo de proyecciones de MergeTree.max_table_size_bytes_compressed
Si el número total de bytes comprimidos (el tamaño en disco) de todas las partes de datos activas e inactivas de la tabla supera este valor, elINSERT se
interrumpe con la excepción Table size limit exceeded. Las partes inactivas
también se contabilizan, ya que el propósito de esta configuración es limitar el uso
de disco. Tenga en cuenta que las partes inactivas se eliminan en segundo plano (consulte
la configuración old_parts_lifetime), por lo que el tamaño observado puede disminuir con el tiempo.
El límite se comprueba al inicio del INSERT y cuando se hace commit de
nuevas partes de datos en el conjunto de trabajo, incluidos los resultados de las fusiones
en segundo plano y las mutaciones. También se comprueban las inserciones realizadas por vistas materializadas. El
límite no se comprueba en los fetches replicados, lo que da lugar a una condición de carrera
cuando inserciones paralelas en varias réplicas sobrepasan el límite. Siempre se permite hacer commit de
partes de datos vacías, de modo que los datos puedan eliminarse de una tabla
que supere el límite, por ejemplo, con TRUNCATE o ALTER TABLE ... DROP PARTITION.
Valores posibles:
- Cualquier número entero positivo.
- 0 — sin límite.
max_table_size_bytes_uncompressed
Igual quemax_table_size_bytes_compressed, pero el límite se aplica al
número total de bytes sin comprimir en todas las partes de datos activas e
inactivas de la tabla.
Valores posibles:
- Cualquier número entero positivo.
- 0 — sin límite.
max_table_size_rows
Si el número total de filas en las partes de datos activas de la tabla supera este valor, elINSERT se interrumpe con la excepción Table size limit exceeded.
El límite se comprueba al inicio del INSERT y cuando se hace commit de nuevas
partes de datos en el conjunto de trabajo, incluidos los resultados de las
fusiones y mutaciones en segundo plano (de modo que una mutación que haga crecer la tabla
por encima del límite se reintentará sin llegar a completarse). También se comprueban las inserciones realizadas por
vistas materializadas. El límite no se comprueba en los fetch replicados,
lo que da lugar a una posible condición de carrera cuando inserciones paralelas en varias
réplicas superan el límite. Siempre se permite hacer commit de partes de datos vacías,
de modo que se pueden eliminar datos de una tabla que supere el límite, por ejemplo con
TRUNCATE o ALTER TABLE ... DROP PARTITION.
Valores posibles:
- Cualquier entero positivo.
- 0 — sin límite.