PostgreSQL中Xmin查询未使用并行顺序扫描的问题咨询

我正在开发一款应用，该应用使用两个不同的SQL查询。针对同一PostgreSQL表对这两个查询执行EXPLAIN ANALYZE分析性能：

查询1：Xmin查询 #

explain analyze
select * from table where xmin::text::bigint >= xmin_max_value;

执行输出：

Seq Scan on users  (cost=0.00..91302235.56 rows=666658645 width=141) (actual time=1686004.249..1686004.250 rows=0 loops=1)
  Filter: (((xmin)::text)::bigint >= xmin_max_value)
  Rows Removed by Filter: 2000000000
Planning Time: 3.066 ms
Execution Time: 1686004.308 ms

查询2：无索引字段查询 #

explain analyze
select * from "2b_users".users where age > max_age;

执行结果：

Gather  (cost=1000.00..56720318.43 rows=1 width=141) (actual time=545081.498..545083.143 rows=0 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  ->  Parallel Seq Scan on users  (cost=0.00..56719318.33 rows=1 width=141) (actual time=545071.505..545071.505 rows=0 loops=3)
        Filter: (age > 100)
        Rows Removed by Filter: 666666667
Planning Time: 0.153 ms
Execution Time: 545083.178 ms

两个查询预期均无数据返回，针对执行计划的差异，有以下疑问：

1. PostgreSQL查询规划器如何判定是否执行并行顺序扫描？两者均为无索引字段，我本以为会生成相同的查询计划。
2. 我知道xmin是系统列，是否系统列存在某种特性导致查询规划器无法执行并行扫描？官方文档未对此进行说明。
3. 是否存在方法或配置可为xmin查询启用并行扫描？并行扫描速度更快，我希望该查询也能利用并行扫描优化性能。

1. 并行顺序扫描的判定逻辑 #

查询规划器是否选择并行扫描，核心看过滤条件的选择性估算和并行执行的成本收益比：

• 对于age查询，规划器能通过字段统计信息准确估算出age > 100的返回行数极少（仅1行），认为多worker分摊全表扫描的成本后，整体执行效率会提升，收益大于并行的额外开销（比如worker间的协调、数据分发），因此选择并行顺序扫描。
• 而xmin查询中，你对xmin做了::text::bigint的连续类型转换，PostgreSQL的统计信息里没有存储这个转换后表达式的数值分布，规划器只能做非常粗糙的行数估算（直接给出了约6.6亿行的高估算值）。当规划器认为返回行数很多时，会判断并行扫描的额外开销超过收益，因此选择普通顺序扫描。

2. xmin系统列是否限制并行扫描 #

xmin本身作为系统列，并不直接阻止并行扫描，问题出在类型转换操作导致的统计信息缺失。如果直接使用xmin的原始类型（xid）做过滤（比如xmin >= '12345'::xid），规划器能获取到xmin的统计数据，正常估算行数，完全有可能触发并行扫描。

3. 为xmin查询启用并行扫描的方法 #

有几种可行方案，按优先级推荐：

• 避免不必要的类型转换：将xmin_max_value转换为xid类型，直接和xmin比较，改写查询为：

  explain analyze
  select * from table where xmin >= xmin_max_value::xid;
  

  这样规划器能利用xmin的原生统计信息，准确估算行数，自然会考虑并行扫描。
• 创建表达式统计信息：如果必须保留类型转换逻辑，可以为转换后的表达式创建专门的统计对象，让规划器能准确估算选择性：

  CREATE STATISTICS xmin_conversion_stats ON users ((xmin::text::bigint));
  ANALYZE users;
  

• 临时调整并行配置：调低parallel_setup_cost（并行初始化成本）或parallel_tuple_cost（每行并行处理成本），让规划器更倾向于选择并行扫描，但这是全局配置，会影响所有查询，仅适合临时测试，不建议长期启用：

  SET parallel_setup_cost = 100; -- 默认是1000，调低后降低并行门槛
  SET parallel_tuple_cost = 0.01; -- 默认是0.1，调低后让规划器认为并行处理每行的成本更低
  

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