postgres 不使用 btree_gist 索引

Question

我有一个巨大的 table，带有一个主键和一个 btree_gist 索引。当我查询 btree_gist 索引中的列时，我希望使用索引并且查询执行得相当快。但是，优化器始终对主键和过滤器执行索引扫描。

示例：

create table test1 (
    id1 bigint not null,
    id2 bigint not null,
    validtime tstzrange not null,
    data float);
alter table test1 add constraint pk_test1 primary key (id1, id2, validtime);
alter table test1 add constraint ex_test1_validtime exclude using gist (id1 with =, id2 with =, validtime with &&);

table 包含大约12亿行，我想知道的查询 returns 只有几百行，但需要很长时间：

select * from test1 where id1=1 and id2=1 and validtime && '[2020-01-01,2020-02-01)';
(about 3s)

查询计划：

explain select * from test1 where id1=1 and id2=1 and validtime && '[2020-01-01,2020-02-01)';
                                        QUERY PLAN                                         
-------------------------------------------------------------------------------------------
 Index Scan using pk_test1 on test1  (cost=0.70..24.68 rows=1 width=46)
   Index Cond: ((id1 = 1) AND (id2 = 1))
   Filter: (validtime && '["2020-01-01 00:00:00+00","2020-02-01 00:00:00+00")'::tstzrange)

性能不好的原因很明显是在时间条件下读取和过滤了万行。

我想知道为什么 postgres 不使用 btree_gist。

我有另一个略有不同的 table，其中使用了 btree_gist，但与我预期的方式截然不同。 table 大约有 1.6 亿行。

create table test2 (
    id1 bigint not null,
    validtime tstzrange not null);                                                                                                                                                                                                                                                                                                                                              
alter table test2 add constraint pk_test2 primary key (id1, validtime);
alter table test2 add constraint ex_test2_validtime exclude using gist (id1 with =, validtime with &&);

在这里，执行计划是这样的：

select * from test2 where id1=1 and validtime && '[2020-01-01,2020-02-01)';
                                                   QUERY PLAN                                                    
-----------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on test2  (cost=1933.19..1937.20 rows=1 width=62)
   Recheck Cond: ((id1 = 1) AND (validtime && '["2020-01-01 00:00:00+00","2020-02-01 00:00:00+00")'::tstzrange))
   ->  BitmapAnd  (cost=1933.19..1933.19 rows=1 width=0)
         ->  Bitmap Index Scan on pk_test2  (cost=0.00..574.20 rows=11417 width=0)
               Index Cond: (id1 = 1)
         ->  Bitmap Index Scan on ex_test2_validtime  (cost=0.00..1358.74 rows=17019 width=0)
               Index Cond: (validtime && '["2020-01-01 00:00:00+00","2020-02-01 00:00:00+00")'::tstzrange)

为什么两次位图索引扫描，使用 btree_gist 索引一次索引扫描就不能全部完成？

Answer 1

终于找到了：

由于查询和索引之间的类型不匹配，因此未使用索引。其实很多地方都提到了，但我只是看了一遍。

1显然不是bigint！有趣的是，使用 btree 主键自动进行转换，而不是 btree_gist.

总之，此查询一切正常：

select * from test1
where id1=1::bigint and id2=1::bigint
and validtime && '[2020-01-01,2020-02-01)';

学习这个花了我几个小时，我永远不会忘记它！

Answer 2

你的回答是正确的，但我想补充一些背景知识来解释为什么会这样。

PostgreSQL 中的索引只支持属于 operator family of its operator class 的运算符。对于 bigint 上的 GiST 索引，即

SELECT ao.amoplefttype::regtype,
       op.oprname,
       ao.amoprighttype::regtype
FROM pg_opfamily AS of
   JOIN pg_am AS am ON of.opfmethod = am.oid
   JOIN pg_amop AS ao ON of.oid = ao.amopfamily
   JOIN pg_operator AS op ON ao.amopopr = op.oid
WHERE am.amname = 'gist'
  AND ao.amoplefttype = 'bigint'::regtype;

 amoplefttype │ oprname │ amoprighttype 
══════════════╪═════════╪═══════════════
 bigint       │ <       │ bigint
 bigint       │ <=      │ bigint
 bigint       │ =       │ bigint
 bigint       │ >=      │ bigint
 bigint       │ >       │ bigint
 bigint       │ <>      │ bigint
 bigint       │ <->     │ bigint
(7 rows)

这解释了为什么必须强制转换为 bigint 才能使用索引。

如果您习惯使用 PostgreSQL，这会令人感到惊讶，因为 PostgreSQL 不需要这样带有 B-tree 索引的强制转换。解释是 btree 的运算符家族有更多的运算符：

SELECT ao.amoplefttype::regtype,
       op.oprname,
       ao.amoprighttype::regtype
FROM pg_opfamily AS of
   JOIN pg_am AS am ON of.opfmethod = am.oid
   JOIN pg_amop AS ao ON of.oid = ao.amopfamily
   JOIN pg_operator AS op ON ao.amopopr = op.oid
WHERE am.amname = 'btree'
  AND ao.amoplefttype = 'bigint'::regtype;

 amoplefttype │ oprname │ amoprighttype 
══════════════╪═════════╪═══════════════
 bigint       │ <       │ bigint
 bigint       │ <=      │ bigint
 bigint       │ =       │ bigint
 bigint       │ >=      │ bigint
 bigint       │ >       │ bigint
 bigint       │ <       │ smallint
 bigint       │ <=      │ smallint
 bigint       │ =       │ smallint
 bigint       │ >=      │ smallint
 bigint       │ >       │ smallint
 bigint       │ <       │ integer
 bigint       │ <=      │ integer
 bigint       │ =       │ integer
 bigint       │ >=      │ integer
 bigint       │ >       │ integer
(15 rows)

bigint和integer之间的相等比较也在其中。

如果您使用 >= 和 < 而不是 && 编写条件，则可以使用常规 B-tree 索引来支持您的查询，这将使强制转换是不必要的，但是如果已经存在来自排除约束的索引，您当然不想创建第二个索引。

postgres 不使用 btree_gist 索引

postgres not using btree_gist index

postgresql

btree-gist