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.
