Time column of an explain plan

Question

Hi,
I'm using Oracle version 10.2.0.3.0. I have 2 tables with 10 million records each. The DDL is as follows.
create table bigtable(col1 varchar2(20), col2 varchar2(20))
create table bigtablechild(col1 varchar2(20), col2 varchar(20))
bigtablechild.col1 is a foreign key to bigtable.col1. Below is the query and explain plan. Over several executions, the query runs for about 20 seconds before returning results. Could anyone please explain what the time column represents? It doesn't match the time it took to return results.
SQL> set autotrace on
SQL>
SQL> select b.col2
  2  from bigtable a, bigtablechild b
  3  where a.col1 = b.col1
  4  and a.col1 = 'ABC6554';
COL2
XYZ6554
XYZ6554
XYZ6554
XYZ6554
XYZ6554
Execution Plan
Plan hash value: 4210396901
| Id  | Operation          | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |               |     5 |   150 | 21538   (4)| 00:04:19 |
|*  1 |  HASH JOIN         |               |     5 |   150 | 21538   (4)| 00:04:19 |
|*  2 |   TABLE ACCESS FULL| BIGTABLE      |     1 |    10 | 13124   (4)| 00:02:38 |
|*  3 |   TABLE ACCESS FULL| BIGTABLECHILD |     5 |   100 |  8413   (5)| 00:01:41 |
Predicate Information (identified by operation id):
   1 - access("A"."COL1"="B"."COL1")
   2 - filter("A"."COL1"='ABC6554')
   3 - filter("B"."COL1"='ABC6554')
Statistics
          0  recursive calls
          0  db block gets
      93672  consistent gets
      91845  physical reads
          0  redo size
        463  bytes sent via SQL*Net to client
        396  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          5  rows processed

Answer 1

Hi,
the values in the TIME column are calculated from cost using system I/O statistics. If dbms_stats.gather_system_stats has never been run, then these stats have default values which may be very far from the truth. In your case, the optimizer expects a single-block I/O read to take about 12 ms, while in reality it is closer to 1 ms, thus the discrepancy between the prediction and actual results.
In general, TIME column is not very helpful not just because of potentially incorrect I/O time estimates, but also because it is hard to predict how much data will be found in cash, so I would recommend not to pay too much attention to it (note, however, that A-time column, on the other hand, is extremely useful, but it's only available if rowsource statistics for the plan have been populated).
Best regards,
Nikolay