PostgreSQL视图不存储数据且无法配置并行，是否触发并行扫描取决于查询视图时的实际执行计划；关键在基表统计信息、分区键过滤、避免LIMIT等抑制并行的写法，并通过EXPLAIN验证Parallel Seq Scan节点。
PostgreSQL 的视图本身不存储数据，也不直接控制执行计划；能否触发并行扫描，取决于查询视图时生成的实际执行计划是否满足并行条件——而不是对视图做任何“配置”。
为什么对视图执行 SET 或 CREATE VIEW ... WITH (parallel = on) 没用
PostgreSQL 视图是纯逻辑封装，CREATE VIEW 语句不接受执行参数（如并行设置），也没有 WITH 子句支持并行策略。你在会话中执行 SET max_parallel_workers_per_gather = 4，影响的是后续所有查询的 planner 行为，但最终是否启用并行，仍由优化器根据底层表结构、统计信息和查询特征动态决定。
- 视图定义里的
SELECT若含小表、高选择性条件、或函数/表达式导致无法分区裁剪，Parallel Seq Scan根本不会出现在执行计划里 - 即使视图基于大分区表，若
WHERE条件未命中分区键（如查sales视图却用user_id = 123而非sale_date），分区裁剪失效，优化器可能放弃并行 -
GROUP BY或ORDER BY若涉及非分布列，Gather Merge节点可能退化为普通Gather，丧失排序并行优势
让视图查询实际走并行扫描的关键动作
真正起作用的操作都在查询发起端和底层表上，不是在视图定义里：
- 确保视图所依赖的基表已启用统计信息：对大表定期运行
ANALYZE，否则优化器低估行数，认为不值得并行 - 检查视图查询是否触发了可并行算子：典型有效场景包括
SELECT COUNT(*) FROM my_view（全表聚合）、SELECT * FROM my_view WHERE sale_date > '2024-01-01'（范围分区键过滤） - 验证执行计划：用
EXPLAIN (ANALYZE, VERBOSE)查看是否出现Parallel Seq Scan或Parallel Index Scan节点，以及Gather是否有多个 worker - 避免在视图定义中写死限制：如
SELECT ... FROM base_table LIMIT 100会让 planner 认为结果集极小，主动禁用并行
max_parallel_workers_per_gather 和视图查询的关系
这个参数只在查询计划阶段生效，且仅当 planner 判定“值得并行”时才起作用。它不区分查询来源是视图还是直接表：
- 值设为 0 → 强制禁用所有并行查询（包括视图）
- 值设为 2，但基表大小
（默认 8MB）→ 仍不会并行 - 值足够大，但视图查询含
FOR UPDATE、WINDOW函数或不可并行函数（如pg_backend_pid()）→ planner 直接排除并行路径
最容易被忽略的一点：视图查询的并行能力完全继承自其展开后的基表访问路径。如果你发现一个视图始终不走并行，别修视图定义，先用 EXPLAIN 看它展开成什么 SQL，再检查那个 SQL 对应的表是否满足并行前提——比如有没有被 VACUUM 过、min_parallel_table_scan_size 是否调得太高、或者分区键是否在 WHERE 中真正参与了裁剪。
