SortMergeJoinExec double counts join key columns in the buffered batch reservation

Abierto
#27,322 3 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@Kristofferjoha ya está trabajando en esto.

Desde el 11/11/2026.

  • #27346 de @Kristofferjoha — abierto

Evaluación

Este issue todavía no se ha evaluado.

Descripción

bug
Describe the bug

SortMergeJoinExec charges a buffered batch twice for each join key that is a plain column. BufferedBatch::try_new adds batch.get_array_memory_size() and the size of each evaluated join key array. When the key is a column reference, the key array shares its buffers with the batch. The reservation then counts that column two times.

Code: https://github.com/apache/datafusion/blob/34eb6dc5b/datafusion/physical-plan/src/joins/sort_merge_join/materializing_stream.rs#L289-L299

The effect is that a join on a wide string key reserves about twice the memory it holds. This makes the join spill or fail under a memory limit earlier than it should.

To Reproduce

Run this in datafusion-cli (commit 34eb6dc5b on main). Both queries buffer the same data. Only the join key differs.

SET datafusion.execution.target_partitions = 2;
SET datafusion.optimizer.prefer_hash_join = false;
CREATE TABLE l AS SELECT value AS id, repeat('x', 1000) || value AS s FROM generate_series(1, 20000);
CREATE TABLE r AS SELECT value AS id, repeat('x', 1000) || value AS s FROM generate_series(1, 20000);

-- join on the wide string column
EXPLAIN ANALYZE SELECT max(l.id), max(r.id), max(l.s), max(r.s) FROM l JOIN r ON l.s = r.s;
-- join on the integer column, same columns kept
EXPLAIN ANALYZE SELECT max(l.id), max(r.id), max(l.s), max(r.s) FROM l JOIN r ON l.id = r.id;

Observed SortMergeJoinExec metrics:

join key peak_mem_used
l.s = r.s 38.8 MB
l.id = r.id 19.7 MB
Expected behavior

Both queries should report about the same peak_mem_used, because the buffered batches are the same. A key array that is a column of the batch should not be charged again.

Additional context

A possible fix is to charge only the key arrays that do not share buffers with the batch (for example, skip Column keys, or count buffers by pointer once per batch).

Related: https://github.com/apache/datafusion/issues/16841 and https://github.com/apache/datafusion/issues/22758.

Lenguaje dominante
Rust
Estrellas
9.6k
Forks
2.6k
Merge medio
3 d 4 h
PR fusionados (30 d)
345

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/datafusion

Todos los issues de apache/datafusion

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.