Re: Type casting and indexes

On Thu, 8 May 2003, David Olbersen wrote:

> Anyway, I've found a (bug|feature|standard?) with type casting and index usage.
>
> I've got a table with a column that's a timestamp with time zone. This
> column is indexed. If I issue the "normal" query of:
>
>     SELECT count(*) FROM foo WHERE bar > '2003-05-05':;timestamp
>
> I get the following EXPLAIN ANALYZE output:
>
> urldb=> explain select count(*) from foo where bar > '2003-05-05'::timestamp;
>                              QUERY PLAN
> ------------------------------------------------------------------------
>  Aggregate  (cost=89960.75..89960.75 rows=1 width=0) (actual time=
>              56706.58..56706.58 rows=1 loops=1)
>    ->  Seq Scan on urlinfo  (cost=0.00..87229.45 rows=1092521 width=0) (actual
>         time=25.37..56537.86 rows=27490 loops=1)
>          Filter: (ratedon > ('2003-05-05 00:00:00'::timestamp without time
>                   zone)::timestamp with time zone)
>  Total runtime: 56706.67 msec
>
> So it seems that the type conversion is killing the use of the index,
> even though the type conversion has to happen for the condition to be
> tested.

IIRC, timestamp->timestamptz is not considered to give a constant value
(ie, is not stable) probably since it depends on timezone settings which
could be changed (for example by a function) during the query, so for each
row the conversion from '2003-05-05 00:00:00'::timestamp without time zone
to a timestamp with time zone can potentially give a different answer.