To_timestamp -vs- to_date and full table scans

Question

Is it expected behavior for the to_timstamp function to negate the use of an index where the to_date does not?
Example:
The query:
SELECT hugea.intkey, hugea.stringkey, hugea.intnum, hugea.stringnum,
hugea.floatnum, hugea.longnum, hugea.doublenum, hugea.bytenum,
hugea.datevalue, hugea.timevalue, hugea.timestampvalue,
hugea.booleanvalue, hugea.charvalue, hugea.shortvalue,
hugea.bigintegervalue, hugea.bigdecimalvalue, hugea.objectvalue
FROM hugea
WHERE hugea.timestampvalue = {ts'2000-01-01 03:21:37[u].0'}
Submitted thru a java application generates the following trace IN ORACLE
=====================
PARSING IN CURSOR #4 len=452 dep=0 uid=65 oct=3 lid=65 tim=18446744071203520496 hv=3183903894 ad='6582cbe4'
SELECT hugea.intkey, hugea.stringkey, hugea.intnum, hugea.stringnum,
hugea.floatnum, hugea.longnum, hugea.doublenum, hugea.bytenum,
hugea.datevalue, hugea.timevalue, hugea.timestampvalue,
hugea.booleanvalue, hugea.charvalue, hugea.shortvalue,
hugea.bigintegervalue, hugea.bigdecimalvalue, hugea.objectvalue
FROM hugea
WHERE hugea.timestampvalue = to_timestamp('2000-01-01 03:21:37.0','YYYY-MM-DD HH24:MI:SS.FF')
END OF STMT
PARSE #4:c=359375,e=355026,p=0,cr=63,cu=3,mis=1,r=0,dep=0,og=4,tim=18446744071203520489
EXEC #4:c=0,e=1253028,p=0,cr=3,cu=0,mis=0,r=0,dep=0,og=4,tim=18446744071204773686
FETCH #4:c=0,e=2055128,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=18446744071206831146
STAT #4 id=1 cnt=0 pid=0 pos=1 obj=30620 op='TABLE ACCESS FULL HUGEA '*** 2004-07-30 16:06:28.000
=====================
The query:
SELECT hugea.intkey, hugea.stringkey, hugea.intnum, hugea.stringnum,
hugea.floatnum, hugea.longnum, hugea.doublenum, hugea.bytenum,
hugea.datevalue, hugea.timevalue, hugea.timestampvalue,
hugea.booleanvalue, hugea.charvalue, hugea.shortvalue,
hugea.bigintegervalue, hugea.bigdecimalvalue, hugea.objectvalue
FROM hugea
WHERE hugea.timestampvalue = {ts'2000-01-01 03:21:[u]37'}
Submitted thru a java application generates the following trace IN ORACLE
PARSING IN CURSOR #4 len=442 dep=0 uid=65 oct=3 lid=65 tim=18446744071260555440 hv=2315259180 ad='65343e30'
SELECT hugea.intkey, hugea.stringkey, hugea.intnum, hugea.stringnum,
hugea.floatnum, hugea.longnum, hugea.doublenum, hugea.bytenum,
hugea.datevalue, hugea.timevalue, hugea.timestampvalue,
hugea.booleanvalue, hugea.charvalue, hugea.shortvalue,
hugea.bigintegervalue, hugea.bigdecimalvalue, hugea.objectvalue
FROM hugea
WHERE hugea.timestampvalue = to_date('2000-01-01 03:21:37','YYYY-MM-DD HH24:MI:SS')
END OF STMT
PARSE #4:c=0,e=1058,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=18446744071260555431
EXEC #4:c=0,e=41,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=18446744071260555686
FETCH #4:c=0,e=58,p=0,cr=4,cu=0,mis=0,r=1,dep=0,og=4,tim=18446744071260557318
STAT #4 id=1 cnt=1 pid=0 pos=1 obj=30620 op='TABLE ACCESS BY INDEX ROWID HUGEA '
STAT #4 id=2 cnt=1 pid=1 pos=1 obj=31428 op='INDEX RANGE SCAN TIMESTAMPVALUE_IX '
Though the problem is related to JAVA/JDBC in this case. The underlying problem (to_date -vs- to_timestamp not acting the same insofar as INDEX utilization) is reproducible within SQL*Plus.
I also tried a function-based index and forced use with hints but had no success.
I'm hoping there is a patch of some kind and that this is simply due to the immaturity of the timestamp datatype.
please advise.

Answer 1

your test is then not relevant. if your table is to small, your statistics too old, your range too big, then oracle will not use an index.
SQL> insert into test_timestamp select timestamp '2000-01-01 00:00:00.00' + numtodsinterval(dbms_random.value,'DAY') from all_objects;
SQL> insert into test_timestamp select timestamp '2000-01-01 00:00:00.00' + numtodsinterval(dbms_random.value,'DAY') from all_objects;
SQL> select count(*) from test_timestamp;
  COUNT(*)
     74706
SQL> analyze table test_timestamp compute statistics;
Table analyzed.
SQL> create index test_timestamp_ix on test_timestamp(ts) compute statistics;
Index created.
SQL> set autot trace exp
SQL> select * from test_timestamp where ts between to_timestamp('2000-01-01','YYYY-MM-DD')  and to_timestamp('2000-01-01 00:00:05.00','YYYY-MM-DD HH24:MI:SS.FF');
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=187 Bytes=2
          057)
   1    0   FILTER
   2    1     INDEX (RANGE SCAN) OF 'TEST_TIMESTAMP_IX' (INDEX) (Cost=
          2 Card=187 Bytes=2057)