PostgreSQL使用距离运算符时为何不触发btree_gist的GIST索引？

当使用<->距离运算符结合GIST索引查询时，PostgreSQL未使用索引，反而执行了并行顺序扫描，相关操作及执行计划如下：

操作SQL #

-- 启用btree_gist扩展以支持timestamp类型的GIST索引
create extension btree_gist;

-- 创建测试表
create table telemetry1(
    time timestamptz primary KEY,
    value DOUBLE PRECISION
);

-- 针对time字段创建GIST索引
create index telemetry1_idx on telemetry1 using gist(time);

-- 插入时间范围为2021-07-24至2021-07-25的测试数据，间隔250毫秒
insert into telemetry1
select t.time, random()
from generate_series(timestamptz '2021-07-24 00:00:00.000000',
                     timestamptz '2021-07-25 23:59:59.000000',
                     interval '250 milliseconds') as t(time);

-- 分析表以更新统计信息
analyze telemetry1;
                 
-- 执行查询并查看执行计划
explain
select * 
from telemetry1 as t
where t.time <-> timestamptz '2021-07-25' = interval '1 year';

执行计划 #

Gather  (cost=1000.00..13603.38 rows=5184 width=16)
  Workers Planned: 2
  ->  Parallel Seq Scan on telemetry1 t  (cost=0.00..12084.98 rows=2160 width=16)
        Filter: (("time" <-> '2021-07-25 00:00:00-03'::timestamp with time zone) = '1 year'::interval)

原因分析 #

1. 查询条件类型限制：GIST索引对<->运算符的优化主要针对范围查询（如distance < X），而非精确等于的条件。PostgreSQL优化器判断，针对"距离等于1年"的条件，全表扫描过滤的成本更低。
2. 数据范围不匹配：测试数据时间范围仅覆盖2021-07-24至2021-07-25，与2021-07-25相差1年的时间点不在此范围内，实际无符合条件的记录，优化器更倾向于选择全表扫描。
3. 主键索引的存在：表已存在time字段的BTREE主键索引，对于timestamp类型的精确查询，BTREE索引效率优于GIST索引，等于条件下优化器仍判断全表扫描更高效。

解决建议 #

• 改用范围查询：若需求是查找距离目标时间在某个范围内的记录，将条件改为范围判断，例如：

  explain
  select * 
  from telemetry1 as t
  where t.time <-> timestamptz '2021-07-25' <= interval '1 hour';
  

  此时GIST索引会被正常使用，利用空间索引特性快速过滤符合范围的记录。
• 转换为精确时间查询：若确实需要精确匹配距离，可先计算出目标时间的偏移值，改用=条件查询，例如：

  explain
  select * 
  from telemetry1 as t
  where t.time = timestamptz '2021-07-25' - interval '1 year'
     or t.time = timestamptz '2021-07-25' + interval '1 year';
  

  该方式会利用主键的BTREE索引，查询效率更高。

内容的提问来源于stack exchange，提问作者C. German Tejero