rows from 是 postgresql 的语法糖，用于横向拼接多个集合返回函数的结果，不提供并行能力；所有函数串行执行，按最长结果集对齐补 null，与并行查询无关。
ROWS FROM 本身不提供并行能力，它只是 PostgreSQL 的语法糖，用于将多个集合返回函数（SRF）的结果横向拼接成一行或多行。它和「并行查询」没有直接关系——PostgreSQL 的并行执行由优化器基于表扫描、聚合、连接等操作自动触发，不作用于函数调用本身，更不会因为用了 ROWS FROM 就让函数并发执行。
如果你看到某些场景下「多个函数看起来并行运行了」，那其实是误解：每个函数仍是串行调用，ROWS FROM 只是把它们的输出对齐合并，类似 CROSS JOIN LATERAL 的简化写法，但无并发语义。
ROWS FROM 是什么？什么时候该用？
- 它用于同时调用多个集合返回函数（如
unnest()、generate_series()、自定义 SRF），并按行对齐输出。 - 所有函数仍按顺序执行，结果集长度取最长那个（短的补 NULL）。
- 不涉及后台 worker，不消耗
max_parallel_workers_per_gather资源。
示例：
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
SELECT * FROM ROWS FROM ( unnest(ARRAY[1,2,3]), unnest(ARRAY['a','b']), generate_series(10,12) ) AS t(x, y, z);
输出三列，共 3 行（以 generate_series 长度为准），y 第三行为 NULL —— 这是「对齐」，不是「并行」。
真正想并行执行多个函数？得换思路
PostgreSQL 不支持函数级并行调度（即不能像 Oracle 的 PARALLEL_ENABLE 那样声明函数可并行）。但你可以间接达成类似效果：
- 把函数逻辑下推到 CTE 或子查询中，并确保其底层访问的是大表 + 满足并行条件（如全表扫描、带 GIN 索引的全文检索等）；
- 用
UNION ALL拆分同一逻辑为多个独立子查询，让优化器分别评估是否启用并行（例如各自扫不同分区）； - 若函数封装了复杂计算，考虑改写为 SQL 内联表达式或物化为临时表，再走并行 Seq Scan / Hash Join；
- 避免在 SELECT 列表里调用高开销 SRF，尤其当外层有大量行时 —— 它会放大执行次数，且无法并行化。
容易踩的坑
- 认为
ROWS FROM (func1(), func2())会让func1和func2并发执行 → 实际仍是串行，且可能因中间结果未缓存而重复计算； - 在
WHERE或JOIN条件中嵌套 SRF 并期待并行加速 → 优化器通常不对此类节点启用并行； - 修改
max_parallel_workers_per_gather = 0后发现ROWS FROM查询变慢 → 其实它本来就不走并行，变慢大概率是其他计划变更（如索引失效、统计信息过期）导致。
真正影响并行性的，永远是：
表大小 ≥ min_parallel_table_scan_size、
执行节点类型是 Parallel Seq Scan / Parallel Index Scan / Parallel Hash Join 等、
且 Gather 节点出现在 EXPLAIN 输出顶层或关键路径上。
ROWS FROM 出现在 EXPLAIN 里，你只会看到 Function Scan，不会有 Workers Planned 字样。这点很关键，别被表象骗了。
