The wait interface is about when you are *not* on CPU, ie, you are waiting for something to complete (eg a physical IO) before you can then consume CPU.
If you are *already* on CPU, eg, logical IO, then no waits will be recorded because you are not waiting for anything.
For example,
SQL> drop table T purge;
Table dropped.
SQL> create table T (x int primary key);
Table created.
SQL> insert into T values (1);
1 row created.
SQL> commit;
Commit complete.
SQL> select event, time_waited_micro
2 from v$session_event
3 where sid = sys_context('USERENV','SID');
EVENT TIME_WAITED_MICRO
---------------------------------------------------------------- -----------------
Disk file operations I/O 51359
control file sequential read 2269
enq: RO - fast object reuse 3780
log file sync 1289
db file sequential read 62818
db file scattered read 3487
SQL*Net message to client 472
SQL*Net message from client 133222790
SQL*Net break/reset to client 122
events in waitclass Other 2891
10 rows selected.
SQL> select count(*)
2 from (
3 select x
4 from T
5 connect by x <= x
6 )
7 where rownum < 1000000;
COUNT(*)
----------
999999
SQL> select event, time_waited_micro
2 from v$session_event
3 where sid = sys_context('USERENV','SID');
EVENT TIME_WAITED_MICRO
---------------------------------------------------------------- -----------------
Disk file operations I/O 51359
control file sequential read 2269
enq: RO - fast object reuse 3780
log file sync 1289
db file sequential read 62818
db file scattered read 3487
SQL*Net message to client 477
SQL*Net message from client 133286910
SQL*Net break/reset to client 122
events in waitclass Other 2891
10 rows selected.
Notice how none of the wait times went up (besides sqlnet coming back to my screen), because the query I ran was simply burning CPU on a single row table (which was already in the buffer cache).
Dont forget that the SECONDS_IN_WAIT time in v$session (and v$session_Wait) is either the time spent waiting *or* the time since the *last* wait. So you might be doing a physical IO intermittently (which you see in the wait details in v$session) and then burning a lot of CPU (none of which will record any waits).
So my inclination is still toward a tightly bound logical IO style execution of an SQL.
Hope this helps.
A nice dtrace example here
http://blog.tanelpoder.com/2009/04/24/tracing-oracle-sql-plan-execution-with-dtrace/