Postgres 不使用日期字段索引

Question

我创建了类似的索引

CREATE INDEX bill_open_date_idx ON bill USING btree(date(open_date));

和，

Column      |            Type
open_date   | timestamp without time zone

并解释分析如下

情况1

explain analyze select * from bill where open_date >=date('2018-01-01');

CREATE INDEX bill_open_date_idx ON bill USING btree(date(open_date));

案例2

explain analyze select * from bill where open_date>='2018-01-01';

Column      |            Type
open_date   | timestamp without time zone

案例3

explain analyze select * from bill where date(open_date) >='2018-01-01';

explain analyze select * from bill where open_date >=date('2018-01-01');

我对为什么会发生这种情况做了足够的研究，但在任何地方都没有适当的解释。只有情况 3使用了我创建的索引，其他情况则不然。为什么会发生这种情况？

据我的理解，情况 2搜索该列的等效字符串open_date，因此它没有使用索引。但为什么不是情况1。另外，如果我错了，请纠正我。

提前致谢！

编辑 1：另外，我很高兴知道到底发生了什么。

以下是要点摘录（https://gist.github.com/cobusc/5875282）

奇怪的是，PostgreSQL 将用于创建索引的函数重写为规范形式，但在 WHERE 子句中使用该函数时（为了匹配索引函数），似乎并没有这样做。

不过，我不清楚为什么 postgres 的开发人员没有想到获取任何附近的匹配索引（或者在我显式转换为date情况3之前我的索引是无用的）。考虑到 Postgres 是高度发展和可扩展的。

Answer 1

B 树索引只能用于搜索条件，如果条件如下所示：

<indexed expression> <operator> <expression that is constant during the index scan>

• 必须<indexed expression>是您在语句中使用的表达式CREATE INDEX。

• 必须<operator>属于数据类型和索引访问方法的默认运算符类，或者属于 中指定的运算符类CREATE INDEX。

• 可以<expression that is constant during the index scan>是常量，也可以包含IMMUTABLE函数STABLE和运算符，但不能包含任何内容VOLATILE。

您的所有查询都满足最后两个条件，但只有第三个查询满足第一个条件。这就是为什么只有该查询才能使用索引。

有关详细介绍这一点的文档，请参阅match_clause_to_indexcol以下内容的评论postgresql/src/backend/optimizer/path/indxpath.c：

/*
 * match_clause_to_indexcol()
 *    Determine whether a restriction clause matches a column of an index,
 *    and if so, build an IndexClause node describing the details.
 *
 *    To match an index normally, an operator clause:
 *
 *    (1)  must be in the form (indexkey op const) or (const op indexkey);
 *         and
 *    (2)  must contain an operator which is in the index's operator family
 *         for this column; and
 *    (3)  must match the collation of the index, if collation is relevant.
 *
 *    Our definition of "const" is exceedingly liberal: we allow anything that
 *    doesn't involve a volatile function or a Var of the index's relation.
 *    In particular, Vars belonging to other relations of the query are
 *    accepted here, since a clause of that form can be used in a
 *    parameterized indexscan.  It's the responsibility of higher code levels
 *    to manage restriction and join clauses appropriately.
 *
 *    Note: we do need to check for Vars of the index's relation on the
 *    "const" side of the clause, since clauses like (a.f1 OP (b.f2 OP a.f3))
 *    are not processable by a parameterized indexscan on a.f1, whereas
 *    something like (a.f1 OP (b.f2 OP c.f3)) is.
 *
 *    Presently, the executor can only deal with indexquals that have the
 *    indexkey on the left, so we can only use clauses that have the indexkey
 *    on the right if we can commute the clause to put the key on the left.
 *    We handle that by generating an IndexClause with the correctly-commuted
 *    opclause as a derived indexqual.
 *
 *    If the index has a collation, the clause must have the same collation.
 *    For collation-less indexes, we assume it doesn't matter; this is
 *    necessary for cases like "hstore ? text", wherein hstore's operators
 *    don't care about collation but the clause will get marked with a
 *    collation anyway because of the text argument.  (This logic is
 *    embodied in the macro IndexCollMatchesExprColl.)
 *
 *    It is also possible to match RowCompareExpr clauses to indexes (but
 *    currently, only btree indexes handle this).
 *
 *    It is also possible to match ScalarArrayOpExpr clauses to indexes, when
 *    the clause is of the form "indexkey op ANY (arrayconst)".
 *
 *    For boolean indexes, it is also possible to match the clause directly
 *    to the indexkey; or perhaps the clause is (NOT indexkey).
 *
 *    And, last but not least, some operators and functions can be processed
 *    to derive (typically lossy) indexquals from a clause that isn't in
 *    itself indexable.  If we see that any operand of an OpExpr or FuncExpr
 *    matches the index key, and the function has a planner support function
 *    attached to it, we'll invoke the support function to see if such an
 *    indexqual can be built.