利用PostgreSQL 16窗口函数新特性优化查询

PostgreSQL 16 在窗口函数方面并没有引入并行执行，ROW_NUMBER()、SUM() OVER () 这类操作仍然跑在单线程上。官方文档和源码变更日志里都没有相关支持，倒是有些文章把“并行聚合函数”（比如 string_agg 和 array_agg 的并行版本）和窗口函数搞混了，别被这类标题带偏。

窗口函数在 PostgreSQL 16 中仍不支持并行执行

明确一点：PostgreSQL 16 并没有实现窗口函数的并行化。ROW_NUMBER()、SUM() OVER () 等依然是单线程执行。官方文档和源码变更日志中均无相关支持项。所谓的“并行聚合函数”仅指 string_agg 和 array_agg 这类普通聚合，根本不是窗口上下文里的东西，别被标题误导。

真正提速靠的是增量排序 + 索引协同

PostgreSQL 16 对 SELECT DISTINCT 启用了增量排序（Incremental Sort），窗口函数本身虽然没并行，但其 ORDER BY 子句却能从中受益——前提是底层数据已经按部分键预排序。

• 如果 PARTITION BY a ORDER BY b，并且存在索引 ON t(a, b)，优化器在 16 里会更倾向使用这个索引，扫描过程中复用已经有序的 a 分组边界，从而减少每组内 b 的局部排序开销。
• 和 15 版本对比，相同查询在 16 中 WindowAgg 节点的 actual time 可以下降 30%～50%，尤其当 a 值重复率高、分组粒度粗时（比如百万用户按地区分组），效果更明显。
• 需要留意：必须配合 VACUUM ANALYZE 更新统计信息，否则优化器可能忽略索引，直接走全表扫描。

work_mem 仍是窗口性能第一调节杠杆

窗口函数的排序仍然严格依赖 work_mem，一旦超限就会落盘，这是最容易被忽略的瓶颈。

• 怎么判断是否落盘？运行 EXPLAIN (ANALYZE, BUFFERS)，看 Sort 或 WindowAgg 节点是否显示 Sort Method: external merge Disk。
• 想实时监控用量？盯一下 pg_stat_progress_sort.sort_bytes，如果持续大于当前 work_mem 值，说明已经溢出了。
• 安全调法：在事务内用 SET LOCAL work_mem = '64MB'，避免全局污染。并发查询数 × 单次峰值内存 ≈ 总内存压力，别盲目设到 '256MB'。
• 特别提醒：COPY 并行加载、JOIN 并行哈希这些 16 的新特性，和窗口函数的内存路径完全无关，帮不了排序压力。

嵌套窗口或多重 ORDER BY 依然触发多次排序

一个查询里同时出现 ROW_NUMBER() OVER (PARTITION BY x ORDER BY y) 和 RANK() OVER (PARTITION BY z ORDER BY w)，PostgreSQL 16 仍然会分别执行两套排序流程，不会复用中间结果。

• 这不是 bug，而是当前执行引擎的限制：不同的 PARTITION BY 搭配不同的 ORDER BY 被视为独立窗口，每个窗口各自申请排序内存。
• 优化方向不是等新版本，而是重构逻辑：比如先把 PARTITION BY x 的结果物化到临时表，再在上面跑第二个窗口；或者用 CTE + DISTINCT ON 替换部分场景。
• 别指望 INCREMENTAL SORT 能跨窗口复用——它只对同一排序需求的连续扫描生效，不跨窗口节点。

实际调优时，先盯紧 EXPLAIN ANALYZE 里的 Sort Method 和 actual time，再确认索引覆盖是否完整，最后才动 work_mem。版本新特性是锦上添花，基础执行路径没理清，再新的功能也救不了慢查询。