Re: Huge plain inserts response time bad with db file sequential read wait event.

| Id  | Operation                | Name | Cost  |
-------------------------------------------------
|   0 | INSERT STATEMENT         |      |     1 |
|   1 |  LOAD TABLE CONVENTIONAL | T    |       |
-------------------------------------------------

The #1 above has PLAN_HASH_VALUE = 0 as there's no plan for the CBO to optimize really. Perhaps some shortcut operation is used for such a trivial insert.
The CPU_COST & IO_COST = 0 in V$SQL_PLAN. But there's a hardcoded COST=1 in V$SQL. *2) insert into t values(s.nextval)*

This plan at least has a PLAN_HASH_VALUE > 0 possibly due to additional complexity, but still no CPU & IO COST in V$SQL_PLAN.

| Id  | Operation                | Name | Cost  |
-------------------------------------------------
|   0 | INSERT STATEMENT         |      |     1 |
|   1 |  LOAD TABLE CONVENTIONAL | T    |       |
|   2 |   SEQUENCE               | S    |       |
-------------------------------------------------

*3) insert into t select 1 from dual*

This insert SQL plan has a SELECT component too and that can have any complexity (and needs to be optimized), so you'll have both a populated PLAN_HASH_VALUE and CPU & IO_COST populated.

| Id  | Operation                | Name | E-Rows | Cost (%CPU)|
---------------------------------------------------------------
|   0 | INSERT STATEMENT         |      |        |     2 (100)|
|   1 |  LOAD TABLE CONVENTIONAL | T    |        |            |
|   2 |   FAST DUAL              |      |      1 |     2   (0)|
---------------------------------------------------------------