Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭 适合新手
  • 哪里不对？
#267 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
64/100
Issue 类型
文档
描述清晰度
基本清楚
活跃度
活跃
技术栈
postgresql, python
领域
backend, data-engineering

调研方向

从 docs/limitations.md 开始，issue 将其指定为记录 DataFusion 对 CTE 的重复规划以及将中间结果注册为表这一变通方法的文档位置。将文档描述的行为与报告的 DataFusion 54 限制进行核对，并说明对物化 CTE 的支持和自动决策属于 upstream 工作。读者能够理解该限制并找出变通方法时，即为完成。

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
Python
星标
142
派生
19
平均合并
1 天 9 小时
30 天内合并 PR
9

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

xqlsystems/xarray-sql 的其他 Issue

查看 xqlsystems/xarray-sql 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。