Overaggressive pruning of nested fields(?) breaks some valid queries unless parquet pushdown is disabled

Offen
#27,253 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@ianthetechie arbeitet bereits daran.

Seit 09.11.2026.

  • #27259 von @ianthetechie — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
rust, sql
Bereich
backend, databases

Rechercherichtung

Start with the parquet reproducer in the issue and compare behavior with both pushdown settings enabled and disabled; the regression is reported between DataFusion 53.1.0 and 54.0.0. Trace nested field pruning and predicate pushdown to find why names.common is unavailable while evaluating the filter, then add a regression test for the original query. The issue links open pull request #27259, so check its status and discussion before taking this on.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug
Describe the bug

Valid queries against a parquet table with certain structural characteristics now fail with an execution error: Field common not found in struct.

As noted in the issue title, my guess is that this is due to overaggressive pruning of nested fields during pushdown, but that needs some further verification.

I have worked up a minimal reproducer (below) which you can replicate with the datafusion-cli.

To Reproduce
-- Set up: an external parquet table with a few rows.
-- Apologies for the somewhat oblique construction, but certain DataFusion versions
-- rejected a simpler version with map(['en'], [english]).
COPY (
    SELECT named_struct(
        'primary', local_name,
        'common', map([language], [english])
    ) AS names
    FROM (VALUES ('Local', 'en', 'English'), (NULL, 'en', 'Fallback'), ('', 'en', ''))
        AS input(local_name, language, english)
) TO '/tmp/datafusion-reproducer.parquet' STORED AS PARQUET;

CREATE EXTERNAL TABLE nested_names
STORED AS PARQUET
LOCATION '/tmp/datafusion-reproducer.parquet';

-- These are defaults for a while AFAIK but including for reproducibility.
SET datafusion.execution.parquet.pushdown_filters = true;
SET datafusion.optimizer.enable_leaf_expression_pushdown = true;

-- Expected:
-- +-----------------------------+
-- | nested_names.names[primary] |
-- +-----------------------------+
-- | Local                       |
-- | NULL                        |
-- +-----------------------------+
--
-- Actual:
-- Parquet error: External: External error: Error evaluating filter predicate
-- caused by
-- Execution error: Field common not found in struct
SELECT names.primary
FROM nested_names
WHERE coalesce(names.primary, names.common['en']) <> '';

SET datafusion.execution.parquet.pushdown_filters = false;
SET datafusion.optimizer.enable_leaf_expression_pushdown = false;

-- With BOTH of these settings disabled, it succeeds and returns Local and NULL.
-- It still fails if either one is true.
SELECT names.primary
FROM nested_names
WHERE coalesce(names.primary, names.common['en']) <> '';

-- Hacky SQL workaround: succeeds even with pushdown enabled.
SET datafusion.execution.parquet.pushdown_filters = true;
SET datafusion.optimizer.enable_leaf_expression_pushdown = true;

SELECT names.primary
FROM nested_names
WHERE coalesce(names.primary, map_extract(names.common, 'en')[1]) <> '';
Expected behavior

The original query should succeed as written with syntax like names.common['en'], without needing to disable predicate pushdown or SQL-level hacks.

Additional context

I haven't had a chance to do a full git bisect, but installing a few releases, I've narrowed it quite a bit. Release-wise, the bug first appeared in 54.0.0; 53.1.0 was fine, and it is still broken on main at the time of this writing.

Willingness to contribute

I would like to contribute a fix for this bug, but request guidance from the DataFusion community

Vorherrschende Sprache
Rust
Sterne
9.6k
Forks
2.6k
Ø Merge
3 T. 4 Std.
Gemergte PRs (30 T.)
345

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/datafusion

Alle Issues in apache/datafusion

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.