Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

DataFusion plans a CTE once per reference, so ML queries grow exponentially with depth

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#267 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
64/100
Type d'issue
Documentation
Clarté
Plutôt claire
Activité
Active
Stack technique
postgresql, python
Domaine
backend, data-engineering

Piste de recherche

Commencez par docs/limitations.md, que l’issue désigne comme l’endroit où documenter la planification répétée des CTE par DataFusion et la solution de contournement consistant à enregistrer un résultat intermédiaire comme table. Vérifiez le comportement documenté par rapport à la limitation signalée dans DataFusion 54 et expliquez que la prise en charge des CTE matérialisées et les décisions automatiques sont des travaux à effectuer en amont. Le travail est terminé lorsque les lecteurs peuvent comprendre la limitation et identifier la solution de contournement.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement

DataFusion plans a CTE once for every place that reads it, so a query whose CTEs read earlier CTEs more than once grows exponentially with its depth. DuckDB computes such a CTE once. ML models written in SQL hit this constantly: a layer norm reads its input three times, a residual connection twice, and a message-passing round reads the node states as sender, receiver and residual.

Reproduction

Each CTE joins the previous one with itself:

from datafusion import SessionContext

def query(depth):
    ctes = ["c0 AS (SELECT i, x FROM t)"] + [
        f"c{d} AS (SELECT a.i, a.x + b.x AS x FROM c{d-1} a JOIN c{d-1} b ON a.i = b.i)"
        for d in range(1, depth + 1)
    ]
    return f"WITH {', '.join(ctes)} SELECT SUM(x) FROM c{depth}"

ctx = SessionContext()
ctx.sql("CREATE TABLE t AS SELECT * FROM (VALUES (1, 1.0), (2, 2.0)) v(i, x)").collect()
plan = ctx.sql(query(8)).execution_plan().display_indent()
depth DataFusion operators DataFusion table scans DuckDB 1.5.5 operators
2 16 4 13
4 64 16 23
6 256 64 33
8 1,024 256 43

In the ML benchmarks

The same queries, on DataFusion 54.0.0 through xarray_sql.Context and on DuckDB through xql.register, Intel i7-8700:

Query DataFusion operators DuckDB operators DataFusion DuckDB
1-layer GPT loss, batch 4 (112 lines of SQL) 12,166 120 8.4 s 0.055 s
GraphCast-shaped forecast, 1 processor round 1,816 243 43 s 17 s
GraphCast-shaped forecast, 2 processor rounds 5,948 282 159 s 13 s

A table read through xarray-sql is read again for every inlined copy. With ERA5 registered lazily from GCS, the 1-round forecast spent most of its time waiting on the network, so the benchmark loads its three time steps into memory first.

A training step through ddx (forward and backward) takes 2.7 s on DataFusion, less than the 8.4 s forward query alone, because ddx stores each step of its program as a table.

Upstream

DataFusion is working on this. apache/datafusion#25580 added WITH ... AS MATERIALIZED, in the PostgreSQL dialect only (apache/datafusion#17737), and apache/datafusion#26237 proposes deciding automatically, as PostgreSQL and DuckDB do. Neither is in DataFusion 54.

Options for xarray-sql

  • Once a DataFusion release has AS MATERIALIZED, check that it works with xarray-sql's table providers and the datafusion dialect Context uses, and document it.
  • Follow apache/datafusion#26237, which would fix this without changing queries.
  • Until then, document the behavior in docs/limitations.md, with the workaround: register an intermediate result as a table.
Langage dominant
Python
Étoiles
142
Forks
19
Merge moyen
1 j 9 h
PR mergées (30 j)
9

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de xqlsystems/xarray-sql

Toutes les issues de xqlsystems/xarray-sql

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.