Partitioned INSERT computes partition values from the wrong columns when the input plan ends in a projection
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
Línea de trabajo
Start in crates/datafusion/src/physical_plan/project.rs, then trace PartitionExpr::children, PartitionValueCalculator::calculate, project_with_partition, and IcebergWriteExec. Run the INSERT reproduction with the aliased and reordered columns, inspect the optimized plan and written partition paths, and confirm that partition pruning returns the expected rows after the fix.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug
For partitioned tables, insert_into adds a ProjectionExec that computes the _partition column with PartitionExpr. PartitionExpr reads its source columns by position: PartitionValueCalculator::calculate indexes batch.columns() with positions precomputed from the table schema. But PartitionExpr::children() returns an empty list (project.rs#L210-L212).
Because the expression appears to reference no columns, DataFusion's ProjectionPushdown rule merges the partition projection into a ProjectionExec beneath it and leaves PartitionExpr unchanged. PartitionExpr then runs against the input batch of the lower projection, which has a different column layout.
The data columns are still written correctly, but each data file gets partition values computed from another column. Reads that prune by partition then silently skip those files.
To Reproduce
-- pt: id INT NOT NULL, val INT NOT NULL, partitioned by identity(id)
-- src (MemTable): a INT NOT NULL, b INT NOT NULL, rows (1, 100), (2, 200)
INSERT INTO pt SELECT b AS id, a AS val FROM src;
Optimized physical plan:
IcebergCommitExec: table=ns.pt
IcebergWriteExec: table=ns.pt
ProjectionExec: expr=[b@1 as id, a@0 as val, iceberg_partition_values(id) as _partition]
DataSourceExec: partitions=1, partition_sizes=[1]
The partition values come from column 0 of the source batch (a) instead of from id (b):
- data files are written under
data/id=1anddata/id=2instead ofdata/id=100anddata/id=200 SELECT * FROM ptreturns(100, 1)and(200, 2)SELECT * FROM pt WHERE id = 100returns no rows
Expected behavior
Partition values are computed from the columns being written, however the optimizer rearranges the projections.
Additional context
Any INSERT whose physical input ends in a ProjectionExec that renames, reorders or drops columns is exposed (column aliases, inserts from joins, ...). VALUES and SELECT * from a source with the table's column order work only because the positions happen to line up. The schema check in project_with_partition runs before physical optimization, so it doesn't catch this.
Possible fixes:
- expose the source columns as
Columnchildren, so projection rewrites update them - check the batch schema in
evaluateand resolve source columns by name or field id - compute partition values inside
IcebergWriteExecinstead of in aPhysicalExpr
- Lenguaje dominante
- Rust
- Estrellas
- 30
- Forks
- 30
- Merge medio
- 3 d 19 h
- PR fusionados (30 d)
- 15
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/datafusion-iceberg
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
apache/datafusion-iceberg#100 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
apache/datafusion-iceberg#85 · 1 comentario · 5 reacciones ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
apache/datafusion-iceberg#84 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
apache/datafusion-iceberg#75 ·
Los mantenedores suelen responder en 1 día
-
Slow CI runnersAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 18/100
apache/datafusion-iceberg#74 ·
Los mantenedores suelen responder en 1 día
Todos los issues de apache/datafusion-iceberg
Issues similares
-
binding:python bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
coollabsio/orbit#72 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
bug order-flow studies ui
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
userFRM/egui-charts#2417 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 2 días