Query-Optimizer on Kent Yao

-46% 还是 -2%?规则改写器只在自己家有效

Wed, 27 May 2026 00:00:00 +0000

在 TPC-H 10GB 上,一个学界 SOTA 的规则改写器把平均执行时间从 69.84s 砍到 37.57s,-46%。换到 DSB 10GB,同一个改写器把 32.62s 砍到 31.93s——只有 -2.1%。差距不在 query 难度,而在 benchmark 是不是它的训练集。“规则系统稳定可靠"很多时候是基准过拟合,不是工程事实。

解剖一份让 LLM 改物理计划的 120 行 prompt

Wed, 27 May 2026 00:00:00 +0000

DBPlanBench 让 GPT-5 在 TPC-H SF10 上把 DataFusion 几何平均加速 4.78×。我对着它的 sql_optimization_prompts.py 数了一遍——120 行,方法论 30 行,剩下 90 行全在给 LLM 立合同。这个比例本身就是这条路线最值得抄走的东西。

翻转分支找性能 bug：ETH 的 BFA 方法，以及它对 Spark 意味着什么

Tue, 26 May 2026 00:00:00 +0000

ETH 的一篇新论文用「把优化分支翻一下，看谁更快」这一招，在 PostgreSQL、MySQL、CockroachDB、MariaDB 上挖出 21 个此前未知的性能 bug。方法概念简单，Spark 这边的落地接口意外地齐整 —— spark.sql.optimizer.excludedRules 几乎就是现成的翻转开关。

只让 LLM 改 SQL,几乎什么都不会发生

Tue, 26 May 2026 00:00:00 +0000

在 TPC-H 10GB 上,直接让 GPT-4o 改写 SQL,平均执行时间从 78.81s 降到 74.92s——几乎等于没改。换一个开源 14B 模型,喂 plan、加 reward、训一遍,同样的工作量降到 29.67s。LLM 在 SQL rewrite 上能不能工作,不取决于 LLM 多强,取决于你愿不愿意给它真正能改 SQL 的信号。

LLM 做 Join Order：从 Databricks 的实验,看 Apache Spark 视角下的三层落地阶梯

Mon, 25 May 2026 00:00:00 +0000

Databricks 与 UPenn 把 LLM agent 当成离线 join-order 调优师,在 JOB 113 条查询上拿到 P90 -41% / 几何均值 1.288× 的提速,甚至超过"完美基数估计"。从 Apache Spark 一线视角看,这件事说明了什么、又没说明什么。