I don't think we can interpret it that way when it comes to nested hash joins because unlike (say) a merge join, rows will start coming out of the hash join as soon as we've completed the first half of the join and commenced on the second.
So whilst step3 starts at 612 and is active until 3588, rows can be produced from this join *throughout* this time, rather than just at the end. The +906 suggests the first rows started coming out at then and went through the filter. Its the duration of the underlying join that makes the filter look like its expensive.
An easy way to check this is
- create a table
- find min and max rowid via dba_extents
- compare query times for
select ... from table
select ... from table where rowid between min_rowid and max_rowid
I did that with a 2billion row table
SQL> set timing on
SQL> select max(y), count(*) cnt
2 from tx
3 where rowid >= chartorowid(:start_id) and rowid<=chartorowid(:end_id);
MAX(Y) CNT
---------- ------------
100000 2000000000
Elapsed: 00:00:53.90
SQL>
SQL> select max(y), count(*) cnt
2 from tx
3 where rowid >= chartorowid(:start_id) and rowid<=chartorowid(:end_id);
MAX(Y) CNT
---------- ------------
100000 2000000000
Elapsed: 00:00:54.29
SQL>
SQL> select max(y), count(*) cnt
2 from tx;
MAX(Y) CNT
---------- ------------
100000 2000000000
Elapsed: 00:00:53.95
SQL>
SQL> select max(y), count(*) cnt
2 from tx;
MAX(Y) CNT
---------- ------------
100000 2000000000
Elapsed: 00:00:53.86
SQL>
SQL>