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。版本新特性是锦上添花，基础执行路径没理清，再新的功能也救不了慢查询。
