ajustes de sesión join_*

Estas configuraciones están disponibles en system.settings y se autogeneran a partir del código fuente. Especifica qué algoritmo JOIN se utiliza. Se pueden especificar varios algoritmos, y se elegirá uno disponible para una consulta concreta en función de kind/estrictez y del motor de tabla. La mayoría de los algoritmos afectan a una consulta solo cuando son los seleccionados para ella. Sin embargo, algunos cambian la planificación simplemente por estar incluidos —incluso como alternativa de menor prioridad que finalmente no se selecciona—, porque la decisión se toma antes de elegir el algoritmo. Hay dos efectos de este tipo:

• La inferencia de tipos de las join keys se vuelve más estricta (un merge join no puede combinar claves de tipos diferentes, por ejemplo, String y Nullable(String)). Esto puede cambiar los tipos de resultado de las columnas USING y puede hacer que un join en una tabla con motor Join falle con TYPE_MISMATCH. Se activa con full_sorting_merge y parallel_full_sorting_merge.
• ORDER BY ... LIMIT en el lado preservado de un join obtiene una ordenación explícita en lugar de una lectura en orden de clave primaria, porque se supone que el join interrumpe la lectura ordenada (un merge join inserta su propia ordenación previa al join; un partial merge join vuelve a ordenar los bloques izquierdos; un join que puede producir bloques retrasados tampoco propaga la lectura ordenada). El resultado es el mismo, pero el plan es menos eficiente. Se activa con full_sorting_merge, parallel_full_sorting_merge, partial_merge, prefer_partial_merge, grace_hash y auto, y también con un valor distinto de cero de max_bytes_before_external_join / max_bytes_ratio_before_external_join.

Ambos se aplican incluso cuando la consulta finalmente se ejecuta con hash u otro algoritmo. Si esto no es deseable, no incluya los algoritmos anteriores en join_algorithm para las consultas afectadas. Valores posibles:

• grace_hash

Se utiliza Grace hash join. Grace hash ofrece una opción de algoritmo que permite realizar joins complejos con buen rendimiento y limitar el uso de memoria. La primera fase de un grace join lee la tabla derecha y la divide en N buckets según el valor hash de las columnas clave (inicialmente, N es grace_hash_join_initial_buckets). Esto se hace de forma que cada bucket pueda procesarse de manera independiente. Las filas del primer bucket se añaden a una hash table en memoria, mientras que las demás se guardan en disco. Si la hash table supera el memory limit (por ejemplo, el configurado en max_bytes_in_join), se incrementa el número de buckets y se reasigna el bucket correspondiente a cada fila. Las filas que no pertenezcan al bucket actual se descargan y se reasignan. Admite INNER/LEFT/RIGHT/FULL ALL/ANY JOIN.

• hash

Se utiliza el algoritmo hash join. Es la implementación más genérica y admite todas las combinaciones de kind y estrictez, así como varias join keys combinadas con OR en la sección JOIN ON. Cuando se usa el algoritmo hash, la parte derecha de JOIN se carga en RAM.

• parallel_hash

Una variación de hash join que divide los datos en buckets y construye varias hash tables de forma simultánea, en lugar de una sola, para acelerar este proceso. Cuando se usa el algoritmo parallel_hash, la parte derecha de JOIN se carga en RAM.

• partial_merge

Una variación del algoritmo sort-merge, en la que solo la tabla derecha se ordena por completo. RIGHT JOIN y FULL JOIN solo se admiten con estrictez ALL (SEMI, ANTI, ANY y ASOF no son compatibles). Cuando se usa el algoritmo partial_merge, ClickHouse ordena los datos y los vuelca a disco. El algoritmo partial_merge en ClickHouse difiere ligeramente de la implementación clásica. Primero, ClickHouse ordena la tabla derecha por join keys en bloques y crea un índice min-max para los bloques ordenados. Después, ordena partes de la tabla izquierda por la join key y las combina con la tabla derecha. El índice min-max también se utiliza para omitir bloques innecesarios de la tabla derecha.

• direct

El algoritmo direct (también conocido como nested loop) realiza una lookup en la tabla derecha usando como claves las filas de la tabla izquierda. Es compatible con almacenamientos especiales como Dictionary, EmbeddedRocksDB y tablas MergeTree. Para las tablas MergeTree, el algoritmo envía los filtros de join key directamente a la storage layer. Esto puede ser más eficiente cuando la clave puede usar el primary key index de la tabla para lookups; de lo contrario, realiza escaneos completos de la tabla derecha para cada block de la tabla izquierda. Admite joins INNER y LEFT, y solo join keys de igualdad de una sola columna sin otras condiciones.

• auto

Cuando se establece en auto, primero se prueba hash join y el algoritmo cambia dinámicamente a otro algoritmo si se supera el memory limit.

• full_sorting_merge

Algoritmo sort-merge con ordenación completa de las tablas combinadas antes de realizar el join.

• ie_join

El algoritmo IEJoin basado en ordenación para un JOIN cuya sección ON tiene dos comparaciones de desigualdad (<, <=, >, >=) entre expresiones de las tablas combinadas. Admite ALL INNER/LEFT/RIGHT/FULL JOIN y SEMI/ANTI LEFT/RIGHT JOIN. La posición en la lista establece la prioridad: si aparece después de otros algoritmos, IEJoin se usa solo cuando estos no se aplican (la sección ON no tiene condiciones de igualdad); si aparece primero, se usa siempre que la sección ON tenga dos condiciones de desigualdad. Las condiciones restantes (incluidas las igualdades) se aplican como filtro sobre el resultado del join para ALL INNER JOIN, y se evalúan dentro del operador como una condición residual que afecta a la coincidencia para los demás tipos. Sin ie_join en la lista, un INNER JOIN con solo condiciones de desigualdad se ejecuta como un CROSS JOIN con un filtro, y los demás tipos no son compatibles. Ambas entradas se acumulan en memoria antes de realizar el join: max_rows_in_join y max_bytes_in_join limitan conjuntamente la entrada acumulada de ambos lados (no solo del lado derecho), con la acción ante overflow establecida mediante join_overflow_mode; los índices de ordenación que el operador construye sobre la entrada acumulada no cuentan para el límite. El propio operador join se ejecuta en un único thread; solo se paralelizan las ordenaciones de las entradas previas al join.

• parallel_full_sorting_merge

Igual que full_sorting_merge, pero los joins de igualdad compatibles con hash se segmentan por el hash de las join keys en merge joins independientes por segmento que se ejecutan en paralelo (hasta max_threads), en lugar de un único merge join. Esto mantiene el bajo uso de memoria en streaming de un merge join mientras usa todos los threads, y el resultado no está ordenado. La segmentación por hash mediante las join keys se aplica solo a joins de igualdad simples en tipos de clave cuyo hash coincide con la comparación del merge join, y solo cuando ninguno de los lados ya está ordenado. Se omite en estos casos:

• Joins ASOF y tipos de clave de coma flotante / JSON / Object / Dynamic: sus hashes no son coherentes con la comparación del merge join, por lo que claves iguales podrían terminar en segmentos diferentes.
• Lados que ya están ordenados (una lectura de MergeTree en orden o cualquier entrada preordenada): una dispersión que preserve el orden en los merges por segmento puede bloquear la canalización. En su lugar se conservan la lectura en orden y su optimización read_in_order_use_virtual_row.
• Mientras el iniciador crea un plan distribuido (make_distributed_plan), porque la ordenación dispersa no se puede serializar para la ejecución remota. El plan local de un solo fragmento y los fragmentos por trabajador se vuelven a optimizar con esa configuración desactivada, por lo que aún pueden segmentarse.

Omitirlo desactiva solo esta reescritura, no el paralelismo en general: el join se ejecuta como un único full_sorting_merge, y los lados de MergeTree que se leen en orden aún pueden segmentarse en el origen mediante rangos de primary key (que se ordenan según la misma comparación que usa el join, por lo que las claves iguales permanecen juntas) cuando query_plan_join_shard_by_pk_ranges está habilitado.

• prefer_partial_merge

ClickHouse siempre intenta usar partial_merge join si es posible; en caso contrario, usa hash. Obsoleto, igual que partial_merge,hash.

• default (obsoleto)

Valor heredado; no lo use más. Igual que direct,hash; es decir, intenta usar direct join y hash join (en este orden). Cambia el comportamiento de las operaciones JOIN con estrictez ANY cuando la tabla derecha tiene más de una fila coincidente para una clave. Valores posibles:

• 0 — Si la tabla derecha tiene más de una fila coincidente, solo se une la primera fila encontrada.
• 1 — Si la tabla derecha tiene más de una fila coincidente, solo se une la última fila encontrada.

Véase también:

• cláusula JOIN
• motor de tabla Join
• join_default_strictness

Establece la estrictez predeterminada para las cláusulas JOIN. Valores posibles:

• ALL — Si la tabla de la derecha tiene varias filas coincidentes, ClickHouse crea un producto cartesiano a partir de las filas coincidentes. Este es el comportamiento normal de JOIN en standard SQL.
• ANY — Si la tabla de la derecha tiene varias filas coincidentes, solo se combina la primera que se encuentra. Si la tabla de la derecha tiene solo una fila coincidente, los resultados de ANY y ALL son los mismos.
• ASOF — Para combinar secuencias con una coincidencia incierta.
• Cadena vacía — Si no se especifica ALL o ANY en la consulta, ClickHouse lanza una excepción.

Limita el número de archivos que se pueden usar para la ordenación paralela en operaciones MergeJoin cuando se ejecutan en disco. Cuanto mayor sea el valor de esta configuración, más RAM se usará y menos operaciones de E/S en disco se necesitarán. Valores posibles:

• Cualquier entero positivo a partir de 2.

El límite inferior del promedio de filas por clave en la tabla de la derecha para determinar si la salida debe generarse como una lista de filas en hash join. Define qué acción realiza ClickHouse cuando una operación JOIN alcanza cualquiera de los siguientes límites:

• max_bytes_in_join
• max_rows_in_join

Esta configuración solo se aplica a los valores hash, parallel_hash e ie_join de join_algorithm. Otros algoritmos (por ejemplo, partial_merge, grace_hash, auto) gestionan los límites de forma diferente: mediante volcado a disco, reparticionamiento o cambio de estrategia; consulte join_algorithm. Valores posibles:

• THROW — ClickHouse lanza una excepción y detiene la consulta.
• BREAK — ClickHouse detiene la consulta y no lanza ninguna excepción.

Valor predeterminado: THROW. Véase también

• cláusula JOIN
• motor de tabla Join

Establece el comportamiento de JOIN. Al combinar tablas, pueden aparecer celdas vacías. ClickHouse las rellena de forma distinta según esta configuración. Valores posibles:

• 0 — Las celdas vacías se rellenan con el valor predeterminado del tipo del campo correspondiente.
• 1 — JOIN se comporta igual que en SQL estándar. El tipo del campo correspondiente se convierte en Nullable, y las celdas vacías se rellenan con NULL.