ReaderMX.
alitrack

DuckDB 周报 #10：v1.5.6 发布，v2.0 提速 6 倍

aalitrack约 6 分钟

9 月 28 日，DuckDB 发布了 v1.5.6，这是 1.5（Variegata）线的第六个补丁版本，修了一批正确性问题，也带了安全补丁。手里有 1.5.x 项目的，这周值得升一下。

同一天的官方博客还给了个 v2.0 预览数字：Windows 上跑 TPC-H SF300，总时间从 822 秒降到 129 秒。数字是官方自己测的，测试条件写得清楚，但逐条查询看并不全是碾压。一句话结论：v2.0 的提速是真的，但这周真正该动手的事，是把生产环境升到 1.5.6。

● ● ●

生态变化

版本面：稳定版从 v1.5.5 升到 v1.5.6（9 月 28 日）。v2.0-alpha（代号 Cyanoptera）继续按发布日历朝 10 月的正式版推进。

v1.5.6 值得留意的修复，按官方公告的分类挑重点：

  • 正确性
    ：LIMIT 下推穿过带 OFFSET 的 volatile 投影会算错（#24240）；UNNEST 下推修复（#24119）；Top-N 窗口消除在 ORDER BY 无列引用时会丢 NULL（#24399）；ICU 的 strptime 会在行间泄漏时区状态（#24438），用 ICU 解析带时区字符串的注意这条；Parquet 读写 TIME_NS 修复（#25728）；VARIANT shredding 对 REQUIRED 字段的修复（#26162）
  • 崩溃类
    ：Top-N 遇到 LIMIT 0 直接崩（#25103）；url_decode 配合 TRY() 在字典编码列上段错误（#24427）
  • C API
    ：符号版本统一，全部 v1 API 进入稳定承诺（#24362），写扩展的人会关心
  • 新增 enable_optimistic_write 设置（#26102）

v2.0 的 Windows 数字：官方在一台 Windows 11 25H2、128 GB 内存、12 核 AMD Ryzen AI 300（24 线程）的笔记本上对比了 v1.5.6 和 v2.0.0-dev（alpha43586），TPC-H SF300，每条查询跑两遍取热跑时间。总时间 822 秒对 129 秒，超过 6 倍。但明细里 Q1 是 17.6 秒变 20.0 秒、Q2 是 1.1 秒变 2.0 秒，反而慢了。所以「快 6 倍」是 22 条查询的总分，不代表每条都快。另外 v2.0-dev 的 Windows 客户端现在有扩展可装了；之前从 tarball 装 CLI 可能撞上「扩展还没传到 S3」的空窗期，官方加了个 alpha 版本重定向来堵这个洞。

社区扩展：10 月 2 日到 3 日合并了一波更新，主流是为 v1.5.6 重建——webbed 2.9.3、otlp、oracle_scanner 0.3.1、finance 0.2.22、zim 0.9.3、STAC 0.3.0、firebird 1.1.0、Onager 都在其中。排队等审的还有 read_lines、func_apply、duck_hunt 这批 v2.0（cyanoptera）的 family-C 移植。两个结构变化：新扩展 dc dual-cognition 合并进库；harbor 被移除，作者注明它不再是 DuckDB 扩展了。

● ● ●

用英语写 WHERE 条件的扩展，十天就出来了

9 月 29 日官方博客发了篇《Jev and DuckDB: Plain-English Conditions in SQL》，讲一种新玩法。

背景是 9 月 15 日 TypeSafe AI 发布的 Jev 模型。它不返回文本，返回带概率的类型化答案：是/否判断（对应 SQL 的 BOOLEAN）、单选分类（对应 ENUM，最多 255 个选项）、按标准打分（对应可排序的序数）。官方口径延迟 70 到 500 毫秒，输入 0.042 美元每百万 token，输出免费。

对 DuckDB 意味着什么：十天内社区做出了好几个扩展，把英语条件直接塞进 SQL。第一个 SQL 集成是 Postgres 上的 pg-jev（9 月 17 日），作者四天后被 Actian 收编。DuckDB 这边已经有进社区扩展仓库的 jev，用法：

INSTALL jev FROM community;
LOAD jev;
SET jev_api_key = '...';

SELECT subject, jev_prob(tickets, 'the customer is angry') AS p
FROM tickets
ORDER BY p DESC;

5 万行工单里找愤怒客户，不用先标注数据训练分类器，也不用逐行调 chat 模型再解析文本。有人演示过约 1000 行 CSV 十秒左右出结果。TypeSafe 宣传里的「190 倍提速」出自它自家 workflow 评测，口径是厂商自报，参考就好。

两个提醒：一，这类扩展会把行内容发给第三方 API，敏感数据别用；二，除了 jev 社区扩展（支持 v1.5.5 和 v1.5.6），其他几个端口比如 duckdb-jev 还没进仓库，要自己编译加载。

● ● ●

字符串聚合慢？官方把老手艺写进了性能指南

10 月 2 日的博客《Faster String Aggregations with Dimension Tables》，讲数仓老套路的新用法。

问题：分析负载里全是重复长字符串——站名、产品名、user agent。DuckDB 的字符串是 16 字节结构，超过 12 字节就得跟着指针读全文。GROUP BY 一个字符串列时，每一行都要哈希、比较整个字符串。官方的例子里，荷兰火车停靠数据 380,959 行，站名只有 537 个：Amsterdam Centraal 一个 18 字节的站名重复存了 7,591 次。

解法就是星型模式：把字符串抽进一张小维度表，每个值给一个排好序的窄整数键，聚合在键上做，最后再把字符串 join 回来。键域够窄时，优化器会直接走完美哈希聚合——用键值当数组下标，连哈希都省了。这个模式来自 DuckDB 团队的 Richard Wesley，现在写进了 Performance Guide 的 schema 一节。你的负载里如果有高基数字符串 GROUP BY 在吃内存，值得照着改一遍。

● ● ●

值得一提

主仓这周合了几个有分量的：

  • checkpoint 不再堵写入
    （#25988，10 月 1 日合并）。以前 checkpoint 写某张表时持排他锁，INSERT 和 DELETE 全在等，还会牵出死锁。现在 checkpoint 会把期间提交的写入转写进去，写入与检查点并行，顺手消掉了一类死锁。重度写入负载会直接有感。
  • 无分区窗口函数改走 cross join
    （#26141）。窗口自 join 没有分区时生成 cross join，PR 自带基准 3.000 秒降到 0.251 秒，12 倍。
  • TPC-H/TPC-DS 查询支持 scale factor
    （#26103）。tpch_queries(sf=100) 直接返回对应数据量的官方参数化查询，跑基准方便多了。
  • 上周介绍过的 Window Monotonic Pushdown 出了正确性修复
    （#26395）。PARTITION BY -x 这类递减表达式会生成错误的辅助过滤器、丢匹配行。修复后的策略是只对递增函数生成辅助过滤——直接反转不等号对浮点 NaN 不成立。上周刚合并的优化这周就补了坑，追新优化的风险和节奏可以体会一下。

当前最新稳定版：v1.5.6（2026-09-28 发布）。v2.0 按发布日历排在 10 月。

你现在站在哪：已经升 1.5.6 了、在等 v2.0 正式版、还是正准备照官方指南把字符串聚合改一轮？评论区说一声。

● ● ●

参考来源

  1. 01
    https://duckdb.org/2026/09/28/announcing-duckdb-156.html
  2. 02
    https://duckdb.org/2026/09/29/jev.html
  3. 03
    https://duckdb.org/2026/10/02/dimension-tables.html
  4. 04
    https://github.com/duckdb/duckdb/releases/tag/v1.5.6
  5. 05
    https://github.com/duckdb/duckdb/pull/25988
  6. 06
    https://github.com/duckdb/duckdb/pull/26141
  7. 07
    https://github.com/duckdb/duckdb/pull/26103
  8. 08
    https://github.com/duckdb/duckdb/pull/26395
  9. 09
    https://duckdb.org/community_extensions/extensions/jev
  10. 10
    https://duckdb.org/release_calendar.html

KEEP THE THREAD GOING

更多来源文章