窗口函数慢主因是WindowAgg节点默认单线程执行，因多数需严格有序（如ROW_NUMBER、RANK），即使表支持并行扫描也无法并行；仅无ORDER BY的聚合类（如COUNT(*) OVER PARTITION BY）可并行，且依赖版本与配置。
窗口函数为什么慢？先看执行计划里的 WindowAgg 节点
PostgreSQL 和 Greenplum 中，WindowAgg 节点一出现，基本就说明窗口计算没走并行。即使表本身支持并行扫描（Parallel Seq Scan），默认情况下窗口函数仍强制单线程执行——因为多数窗口函数（如 ROW_NUMBER()、RANK()、SUM() OVER (ORDER BY ...)）要求严格有序，优化器不敢乱拆。
常见错误现象：EXPLAIN (ANALYZE) 显示 WindowAgg 耗时占比超 70%，且 Workers Launched: 0；而上游扫描明明启了 4 个 worker。
- 不是所有窗口函数都支持并行：只有无
ORDER BY的聚合类（如COUNT(*) OVER (PARTITION BY x)）才可能并行 - 有
ORDER BY的必须排序，而排序本身在 PostgreSQL 14+ 才支持并行（需enable_parallel_tuplestore = on，且实际效果有限） - Greenplum 6+ 对
PARTITION BY+ 无ORDER BY场景做了增强，可下推到 segment 并行计算
哪些窗口函数能真正并行？看函数语义和版本支持
能不能并行，不看写法多炫，只看是否满足「可分片聚合再合并」的数学性质。比如：
-
COUNT(*) OVER (PARTITION BY user_id)→ 可并行：各 worker 算自己分片的 count，最后 sum -
AVG(sales) OVER (PARTITION BY region)→ 可并行：算 sum 和 count 两个中间量，再 merge 后除 -
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)→ 不可并行：全局序号依赖跨分片排序结果 -
LAG(sales) OVER (PARTITION BY store ORDER BY day)→ 不可并行：依赖前一行物理位置，无法分片独立算
PostgreSQL 16 开始支持部分带 ORDER BY 的并行窗口（需 parallel_leader_participation = off 强制 leader 不参与计算），但实际生效需配合 work_mem 足够大，否则 fallback 到单线程。
执行计划调优：绕不开的三个配置开关
窗口函数并行不是开个参数就自动生效，得手动撬动几个关键杠杆：
-
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的窗口即使逻辑可并行，也无法用并行排序支撑
注意：这些是会话级设置，别直接改全局配置。临时调优用：
SET max_parallel_workers_per_gather = 4;<br>SET parallel_setup_cost = 0.005;
替代方案比硬刚并行更有效：提前物化 + 分区裁剪
真遇到 ROW_NUMBER() OVER (ORDER BY time) 这种刚需全局序号的场景，并行基本没戏。这时候该放弃「让窗口变快」，转而「让窗口算得少」：
- 用
WHERE time >= '2024-01-01'配合时间分区表，把数据量压到百万级以内，单线程也扛得住 - 把窗口逻辑下推到物化视图或临时表：
CREATE TEMP TABLE tmp_ranked AS<br>SELECT *, ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC) rn<br>FROM fact_sales WHERE dt = '2024-06-01';
再对tmp_ranked做后续过滤，避免每次查询都重算 - 业务允许近似结果时，用
approx_count_distinct()或采样（TABLESAMPLE SYSTEM (1)）代替精确窗口聚合
最常被忽略的一点：窗口函数的 PARTITION BY 列如果没有索引，即使并行开启，每个 worker 仍要各自做 hash partition，CPU 和内存开销翻倍——记得给高频 partition 列建索引。
