能真正并行的窗口函数仅限无ORDER BY的聚合类，如COUNT(*) OVER (PARTITION BY x)和AVG(col) OVER (PARTITION BY y)，因其满足“可分片聚合再合并”语义；而ROW_NUMBER()、RANK()、LAG()等依赖全局排序或物理行序的函数不可并行。
窗口函数在大规模数据上默认单线程执行，WindowAgg 节点不启动 worker 就代表并行被锁死了——这不是配置没开，而是语义或版本不支持。
哪些窗口函数能真正走并行？看语义，不是看写法
能否并行，只取决于“是否可分片聚合再合并”。有 ORDER BY 的绝大多数不行，无序聚合类才可能生效：
-
COUNT(*) OVER (PARTITION BY user_id)→ 可并行：各 worker 算局部 count，最后 sum -
AVG(sales) OVER (PARTITION BY region)→ 可并行：分别算SUM(sales)和COUNT(*)，merge 后除 -
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary)→ 不可并行：序号依赖全局排序结果，无法拆 -
LAG(sales) OVER (PARTITION BY store ORDER BY day)→ 不可并行：必须按物理顺序读前一行，分片后位置关系丢失
PostgreSQL 14+ 并行窗口的三个硬开关
即使函数语义允许，并行也不会自动开启。这三个配置必须手动调：
-
max_parallel_workers_per_gather：至少设为4（默认是2），否则 worker 数被卡死 -
parallel_setup_cost和parallel_tuple_cost：建议调低至0.005和0.001，否则优化器宁可单线程扫完也不拆 -
enable_parallel_tuplestore（PG 14+）：必须ON，否则带ORDER BY的窗口即使能并行也 fallback 到单线程
Greenplum 和 PostgreSQL 16 的特殊处理
Greenplum 6+ 对纯 PARTITION BY 场景做了下推优化，能直接在 segment 层并行计算；PG 16 新增了 parallel_leader_participation = off，强制 leader 进程不参与计算，把全部 worker 压给子进程——但这要求 work_mem 足够大，否则仍退回到单线程。
最容易被忽略的一点：并行窗口对数据倾斜极度敏感。如果某个 PARTITION BY 值占全量 80%，那哪怕开了 8 个 worker，实际负载几乎全压在 1 个上——此时索引、分区裁剪或预聚合比调并行参数更管用。
