分区表按分区字段过滤却全分区SEQ SCAN？求排查原因

以下是可能的问题点及对应的处理步骤：

• 分区键与查询条件类型不匹配
  若t_timestamp为timestamp/timestamptz类型，查询中直接使用字符串常量可能导致隐式转换，干扰优化器识别分区边界。建议显式转换类型：

  SELECT ... 
  FROM ptschema.ptable 
  WHERE t_timestamp >= '2022-01-28'::timestamp AND t_timestamp < '2022-02-02'::timestamp
  

  同时确保分区创建时的边界值与字段类型完全一致（例如字段是timestamptz则边界用带时区的时间值）。

• 分区边界定义错误
  检查分区创建语句，确认月分区范围连续且覆盖正确。例如2022年1月分区应定义为FOR VALUES FROM ('2022-01-01') TO ('2022-02-01')，2月分区为FROM ('2022-02-01') TO ('2022-03-01')。若边界设置为'2022-01-31 23:59:59'这类非整点值，查询条件< '2022-02-02'会被优化器判定需扫描更多分区。

• 统计信息未更新
  新插入大量数据后未执行ANALYZE，优化器缺乏分区数据分布的统计信息，无法做出正确的裁剪和索引选择。执行以下命令更新统计信息：

  ANALYZE ptschema.ptable;
  

• 分区索引未正确同步
  分区表的主表索引会自动同步到现有分区，但后期新增的分区需要手动同步或重新创建主表索引。检查各分区的索引情况：

  SELECT tablename, indexname FROM pg_indexes WHERE schemaname = 'ptschema' AND tablename LIKE 'ptable_%';
  

  若存在缺失，重新在主表创建索引：

  CREATE INDEX idx_ptable_t_timestamp ON ptschema.ptable (t_timestamp);
  

• enable_partition_pruning参数未生效
  确认参数的全局或当前session状态：

  SHOW enable_partition_pruning;
  

  若为off，可临时在session级别开启：

  SET enable_partition_pruning = on;
  

  如需全局生效，修改postgresql.conf后重启数据库。

• 优化器成本估算倾向全表扫描
  若查询返回数据占分区比例较高，优化器可能认为全表扫描成本更低。可通过添加排序逻辑测试索引是否可用：

  SELECT ... 
  FROM ptschema.ptable 
  WHERE t_timestamp >= '2022-01-28'::timestamp AND t_timestamp < '2022-02-02'::timestamp
  ORDER BY t_timestamp;
  

  或执行EXPLAIN ANALYZE对比两种扫描方式的成本差异。

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