postgresql 16 未实现窗口函数并行执行，row_number()、sum() over () 等仍单线程运行；仅通过增量排序、索引协同和 work_mem 优化提升性能，而非真正并行化。
窗口函数在 PostgreSQL 16 中仍不支持并行执行
直接说结论：PostgreSQL 16 并未实现窗口函数的并行化，ROW_NUMBER()、SUM() OVER () 等仍为单线程执行。官方文档和源码变更日志中均无相关支持项，所谓“并行聚合函数”仅指 string_agg 和 array_agg 这类普通聚合（非窗口上下文），别被标题误导。
真正提速靠的是增量排序 + 索引协同
PostgreSQL 16 对 SELECT DISTINCT 启用了增量排序（Incremental Sort），而窗口函数本身虽未并行，但其 ORDER BY 子句可从中受益——前提是底层数据已按部分键预排序。
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 如果
PARTITION BY a ORDER BY b，且存在索引ON t(a, b)，PostgreSQL 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。版本新特性是锦上添花，基础执行路径没理清，再新的功能也救不了慢查询。
