Navicat里点“解释”看不到Parallel节点，是因为PostgreSQL 10+虽支持并行查询但默认关闭，需确认服务端配置（如max_parallel_workers_per_gather>0）、查询满足并行条件（无volatile函数、非写操作），并手动使用EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)语句配合勾选Include analyze/buffers才能正确渲染Parallel Seq Scan等节点。
Navicat里点“解释”看不到Parallel节点？先确认PostgreSQL版本和配置
postgresql 10+ 才支持并行查询，但默认是关闭的。navicat 能否显示 parallel seq scan、parallel index scan 这类节点，取决于服务端是否启用并行能力，不是客户端能决定的。
常见错误现象：EXPLAIN 输出里完全没有 Parallel 字样，或 Navicat 执行计划窗口只显示普通 Seq Scan —— 这说明服务端压根没走并行路径。
- 检查
max_parallel_workers_per_gather是否 > 0（默认为 2，但某些部署被设为 0） - 确认
parallel_setup_cost和parallel_tuple_cost没被调得过高（比如设成 1000），导致优化器直接放弃并行 - 确保查询本身适合并行：不能含 volatile 函数（如
now()、random()）、不能是写操作、不能在事务中带FOR UPDATE - Navicat 15 及更早版本对 PostgreSQL 14+ 的
Parallel Append或Gather Merge节点渲染不全，建议升级到 Navicat 17
在Navicat中正确触发并行执行计划的实操步骤
Navicat 默认用的是 EXPLAIN (FORMAT TEXT)，它会省略很多并行细节。要看到真实并行行为，必须手动构造语句并控制输出格式。
- 在查询编辑器中写完整语句：
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) SELECT ...——FORMAT JSON是关键，Navicat 能解析 JSON 并展开 Parallel 分支；TEXT 格式会把并行子节点折叠成一行 - 务必勾选界面右上角的 Include analyze 和 Include buffers，否则看不到实际 worker 数量、shared hit/reads 等核心指标
- 避免在语句末尾加
;（PostgreSQL 的EXPLAIN ANALYZE不接受分号结尾，否则 Navicat 会静默失败） - 如果目标表小于
min_parallel_table_scan_size（默认 8MB），即使配置全开也不会触发并行，可临时设为SET min_parallel_table_scan_size = '1MB';测试
看懂并行计划里最关键的三处字段
Navicat 渲染的 JSON 格式执行计划是树状结构，别从顶层往下读。直接定位这三个位置：
-
Workers Launched：出现在Gather或Gather Merge节点下，数字就是实际启动的 worker 数（如"Workers Launched": 2）。为 0 就等于没并行 -
Actual Total Time下方的Workers数组：每个 worker 的耗时、rows、shared_blks_read 等，对比主进程看负载是否均衡 -
Plans字段下的子节点：真正的并行扫描节点（如Parallel Seq Scan）一定嵌套在Gather的Plans里，而不是平级出现
注意：如果 Workers Launched 是 2，但 Plans 里只有一个子节点，说明并行被降级了——大概率是内存不足（work_mem 太小）或统计信息过期（ANALYZE table_name 没跑）。
为什么用EXPLAIN ANALYZE测并行反而比单线程还慢？
并行不是万能加速器。Navicat 里点 Explain Analyze 后发现总耗时暴涨，往往是因为协调开销压倒收益。
- 小结果集（
rows ）几乎从不受益于并行，<code>Gather节点本身的同步成本就可能超过扫描节省的时间 - 高并发场景下，多个并行查询争抢
max_parallel_workers全局槽位，导致排队等待，EXPLAIN ANALYZE显示的Planning Time会异常升高 - 若查询涉及大量
shared_blks_read，而磁盘是 HDD 或网络存储，多 worker 同时读容易引发 I/O 争抢，实际吞吐反而下降 - Navicat 不会自动加
SET statement_timeout = '30s'，一旦并行卡住（如等锁、等 buffer），你得手动中断，否则窗口一直转圈
真正需要关注的不是“有没有并行”，而是“并行是否带来净收益”。用 EXPLAIN (ANALYZE, BUFFERS) 对比开启/关闭并行（SET max_parallel_workers_per_gather = 0）的 Actual Total Time 和 Shared Hit Ratio，才说得清。
