navicat 不显示 parallel 节点是因 postgresql 服务端未启用并行查询，常见原因包括 max_parallel_workers_per_gather=0、并行成本参数过高或查询含 volatile 函数；需用 explain (analyze, format json) 查看 workers launched 等指标，小表还受 min_parallel_table_scan_size 限制。
Navicat 里看不到 Parallel 节点？先确认服务端是否真启用并行
Navicat 点「解释」没出现 Parallel Seq Scan 或 Gather，不是客户端问题，而是 PostgreSQL 服务端压根没走并行路径。常见原因有三：
• max_parallel_workers_per_gather 被设为 0（默认是 2，但很多生产环境被关掉）
• parallel_setup_cost 或 parallel_tuple_cost 被调得过高（比如设成 1000），优化器直接放弃并行
• 查询本身不满足并行条件：含 now()、random() 等 volatile 函数，或带 FOR UPDATE、在未提交事务中执行
必须用 FORMAT JSON + ANALYZE 才能看清线程分配细节
Navicat 默认用 EXPLAIN (FORMAT TEXT)，会把并行子节点折叠成一行，根本看不到 worker 数量和各线程耗时。要真实还原并行结构，必须手动写语句：
• 在查询编辑器中输入完整命令：EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) SELECT ...
• 务必勾选界面右上角的 Include analyze 和 Include buffers，否则 Workers Launched 和 shared_blks_read 这些关键字段不会渲染
• 别在语句末尾加分号——EXPLAIN ANALYZE 不接受分号结尾，Navicat 会静默失败，无任何提示
从 JSON 计划里定位三个核心并行指标
别从顶层节点往下读，直接搜这三处：
• Workers Launched：出现在 Gather 或 Gather Merge 节点下，数字就是实际启动的 worker 数（如 "Workers Launched": 2）；为 0 就等于没并行
• Actual Total Time 下方的 Workers 数组：每个 worker 的独立耗时、rows、shared_blks_read，能看出负载是否倾斜（比如一个 worker 耗时 800ms，另两个只花 200ms）
• Buffers 字段中的 shared hit/read/dirty：若 read 明显高于 hit，说明并行线程大量触发物理 I/O，可能 buffer pool 不足或表太大
小表或低开销查询永远不触发并行，别被配置误导
即使所有参数都设对了，min_parallel_table_scan_size（默认 8MB）也会拦住小表。比如一张只有 2MB 的表，哪怕你设了 max_parallel_workers_per_gather = 4，也不会启动并行。临时验证可用：
• 先执行：SET min_parallel_table_scan_size = '1MB';
• 再跑 EXPLAIN (ANALYZE, FORMAT JSON)，看 Workers Launched 是否出现
• 注意：这个 SET 只对当前会话有效，不影响其他连接
真正影响线程分配的，从来不是 Navicat 界面按钮，而是服务端对数据规模、成本阈值和函数稳定性的综合判断——它不信任 volatile，也不为 10 行数据启动 4 个 worker。
