PostgreSQL复杂JOIN出现多Parallel Seq Scan致查询缓慢求助

问题SQL #

select max(db.tableA."id")
from db.tableA
         left outer join db.tableB
                         on (db.tableB.column1 = db.tableA.column1
                            and db.tableB.column2 = db.tableA.column2
                            and db.tableB.column3 = db.tableA.column3
                            and db.tableB.column4 = db.tableA.column4)
where (db.tableA.column1 = 'SOME_VALUE'
       and db.tableA.column2 in ('some', 'list', 'of', 'values')
       and db.tableB.column2 is null)

该SQL偶尔执行耗时可达20秒，通过EXPLAIN ANALYZE查看执行计划，发现存在大量针对不同chunk的**Parallel Seq Scan（并行顺序扫描）**步骤，片段如下：

执行计划片段（翻译后） #

->  部分聚合  (成本=11704.05..11704.06 行数=1 宽度=8) (实际时间=62.069..62.110 行数=1 循环=5)
              ->  Hash反连接  (成本=34.58..11679.12 行数=9970 宽度=8) (实际时间=62.064..62.105 行数=0 循环=5)
                    Hash条件: ((_hyper_1_11005_chunk.column1 = tableB.column1) AND (_hyper_1_11005_chunk.column2 = tableB.column2) AND (_hyper_1_11005_chunk.column3 = tableB.column3) AND (_hyper_1_11005_chunk.column4 = tableB.column4))
                    ->  并行追加  (成本=0.02..11369.08 行数=11389 宽度=29) (实际时间=0.038..47.278 行数=11262 循环=5)
                          ->  并行顺序扫描 _hyper_1_11005_chunk  (成本=0.02..462.20 行数=1667 宽度=29) (实际时间=0.041..13.213 行数=2834 循环=1)
                                过滤条件: ((column1 = 'SOME_VALUE'::text) AND (column2 = ANY ('{some, list, of, values}'::text[])))

现有索引（省略主键索引） #

TableA #

• (column1, column2, column3, column4)

TableB #

• (column1, column2)

原因分析 #

1. 索引覆盖性不足：TableA的现有联合索引虽然前缀匹配查询的过滤条件（column1、column2），但未包含聚合所需的id列。即使走索引，也需要回表读取id，PostgreSQL评估后认为这种方式的成本高于并行顺序扫描。
2. 数据分布与统计信息：从执行计划看，每个chunk中符合过滤条件的数据占比不低（实际返回行数2834，预估1667），说明统计信息可能存在偏差，或者实际数据中符合条件的记录占比过高。当数据占比超过一定阈值（通常20%-30%），顺序扫描的IO效率会优于索引扫描。
3. Hypertable chunk特性：TableA是TimescaleDB的超表（从_hyper_前缀的chunk表可判断），每个chunk是独立物理表。优化器会对每个chunk单独评估扫描策略，若多个chunk中符合条件的数据占比都较高，就会触发大量并行顺序扫描。

优化建议 #

1. 创建覆盖索引（优先方案）：为TableA创建包含过滤条件和id列的覆盖索引，避免回表操作：

   CREATE INDEX idx_tableA_col1_col2_id ON db.tableA (column1, column2) INCLUDE ("id");
   

   如果需要保留原联合索引的查询能力，也可以在原索引基础上追加id列：

   CREATE INDEX idx_tableA_col1_col2_col3_col4_id ON db.tableA (column1, column2, column3, column4) INCLUDE ("id");
   

2. 优化TableB的连接索引：当前TableB的索引仅包含column1、column2，无法覆盖连接所需的4列，创建全连接列的联合索引可提升Hash反连接效率：

   CREATE INDEX idx_tableB_col1_col2_col3_col4 ON db.tableB (column1, column2, column3, column4);
   

3. 更新统计信息：执行以下命令确保优化器拥有准确的数据分布情况：

   ANALYZE db.tableA;
   ANALYZE db.tableB;
   

4. 调整并行参数（临时方案）：若并行扫描开销过高，可临时调整max_parallel_workers_per_gather参数，但优先通过索引和统计信息解决根本问题。

内容的提问来源于stack exchange，提问作者Johnczek