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');

Seq Scan on bill  (cost=0.00..345264.60 rows=24813 width=1132) (actual time=0.007..1305.730 rows=5908 loops=1)    
    Filter: (open_date >= '2018-01-01'::date)    
    Rows Removed by Filter: 3238812  
Total runtime: 1306.176 ms

СЛУЧАЙ 2

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

Seq Scan on bill  (cost=0.00..345264.60 rows=24813 width=1132) (actual time=0.006..1220.697 rows=5908 loops=1)    
  Filter: (open_date>= '2018-01-01 00:00:00'::timestamp without time zone)       
  Rows Removed by Filter: 3238812  
Total runtime: 1221.131 ms

СЛУЧАЙ 3

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

Index Scan using idx_bill_open_date on bill  (cost=0.43..11063.18 rows=22747 width=1132) (actual time=0.016..4.744 rows=5908 loops=1)
    Index Cond: (date(open_date) >= '2018-01-01'::date)  
Total runtime: 5.236 ms 
(3 rows)

Я достаточно исследовал, почему это происходит, но нигде нет правильных объяснений. Только case 3 использует созданный мной индекс, но не другие. Почему это происходит?

Насколько я понимаю, case 2 ищет строковый эквивалент столбца open_date и, следовательно, не использует индекс. Но почему нет случая 1. Также, пожалуйста, поправьте меня, если я ошибаюсь.

Заранее спасибо!

Edit 1: Кроме того, я был бы рад узнать, что происходит в глубине.

Ниже приводится выдержка из сущности (https://gist.github.com/cobusc/5875282)

Странно, однако, что PostgreSQL переписывает функцию, используемую для создать индекс в каноническую форму, но, похоже, не делает то же самое когда функция используется в предложении WHERE (чтобы соответствовать индексная функция).

Тем не менее, мне неясно, почему разработчики postgres не думали о получении какого-либо близлежащего совпадающего индекса (или мой индекс бесполезен, пока я не приведу явно к date, как в case 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.