Timestamp indexes aren't used for ">="

We have a table which has approximately 400,000 rows.
It has 17 columns, and 4 indexes. The primary key
is a int4 (filled by a sequence), additionally we
have two more int4 indexes and a timestamp index.

The documentation for create index
(http://www.postgresql.org/idocs/index.php?sql-createindex.html)
gives a nice query to display the list of known operators
for each of the index types. Running this yields the
following useful data....

acc_name | ops_name | ops_comp
----------+---------------+----------
btree | timestamp_ops | <
btree | timestamp_ops | <=
btree | timestamp_ops | =
btree | timestamp_ops | =
btree | timestamp_ops | >
btree | timestamp_ops | >=

Now, if this is true.... how can this result be consistant?

(selecting by equality with timestamp value)

explain select fetch_status, count(*)
from stat_fetch where fetch_date = '2001-11-08 00:00:00-05'
group by fetch_status;

NOTICE: QUERY PLAN:

Aggregate (cost=8.05..8.06 rows=1 width=12)
-> Group (cost=8.05..8.05 rows=1 width=12)
-> Sort (cost=8.05..8.05 rows=1 width=12)
-> Index Scan using ix_stat_fetch_3 on stat_fetch
(cost=0.00..8.04 rows=1 width=12)

EXPLAIN

.....BUT.....

(selecting by comparison ">=" to timestamp value)

explain select fetch_status, count(*)
from stat_fetch where fetch_date >= '2001-11-08 00:00:00-05'
group by fetch_status;

NOTICE: QUERY PLAN:

Aggregate (cost=12322.64..12522.06 rows=3988 width=12)
-> Group (cost=12322.64..12422.35 rows=39884 width=12)
-> Sort (cost=12322.64..12322.64 rows=39884 width=12)
-> Seq Scan on stat_fetch (cost=0.00..8917.33
rows=39884 width=12)

EXPLAIN

.....AND YET.....

set enable_seqscan to off;
explain select fetch_status, count(*)
from stat_fetch where fetch_date >= '2001-11-08 00:00:00-05'
group by fetch_status;
NOTICE: QUERY PLAN:

Aggregate (cost=38193.97..38393.39 rows=3988 width=12)
-> Group (cost=38193.97..38293.68 rows=39884 width=12)
-> Sort (cost=38193.97..38193.97 rows=39884 width=12)
-> Index Scan using ix_stat_fetch_3 on stat_fetch
(cost=0.00..34788.66 rows=39884 width=12)

EXPLAIN

Note the cost of the "Index" scan is actually a higher estimate
than the sequential scan.

This leads me to the conclusion that either postgres has a
bug that is preventing it from actually using the operator
that is defined on the index (thus falling back to the non-
indexed comparison), or explain is broken, or my understanding
of indexes is broken.

--
Jeff Boes vox 616.226.9550
Database Engineer fax 616.349.9076
Nexcerpt, Inc. jboes(at)nexcerpt(dot)com