Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
  • Qualcosa non va?
#267 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
64/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
postgresql, python
Ambito
backend, data-engineering

Direzione di ricerca

Inizia da docs/limitations.md, che l’issue indica come il luogo in cui documentare la pianificazione ripetuta delle CTE da parte di DataFusion e la soluzione alternativa di registrare un risultato intermedio come tabella. Verifica il comportamento documentato rispetto alla limitazione segnalata in DataFusion 54 e spiega che il supporto delle CTE materializzate e le decisioni automatiche sono attività a monte. Il lavoro è concluso quando i lettori possono comprendere la limitazione e individuare la soluzione alternativa.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Python
Stelle
142
Fork
19
Merge medio
1g 9h
PR unite (30g)
10

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di xqlsystems/xarray-sql

Tutte le issue di xqlsystems/xarray-sql

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.