Confused by the change in logical IO when using a UNION

Question

Hi,
we were discussing tuning strategies (using SQL*Plus and autotrace) and stumbled over a strange behaviour.
When I do a straight select I get the following output:
SQL> select * from orders where id > 600000;
100000 rows selected.
Execution Plan
Plan hash value: 1275100350
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |        | 99585 |  2236K|   436  (14)| 00:00:07 |
|*  1 |  TABLE ACCESS FULL| ORDERS | 99585 |  2236K|   436  (14)| 00:00:07 |
Predicate Information (identified by operation id):
   1 - filter("ID">600000)
Statistics
          0  recursive calls
          0  db block gets
       9473  consistent gets
          0  physical reads
          0  redo size
    3353061  bytes sent via SQL*Net to client
      73711  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed
SQL>which is more or less what I expected. Now the strange thing comes when I change the statement to
select * from orders where id > 600000 and id < 630000
union
select * from orders where id >= 630000;which selects the same set of data. Of course the execution plan changes for this query, but what really puzzles me is the huge different for logical IO (consistent gets)
SQL> select * from orders where id > 600000 and id < 630000 union select * from orders where id >= 630000;
100000 rows selected.
Execution Plan
Plan hash value: 2377290594
| Id  | Operation                     | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |           | 99587 |  2236K|       |  1242  (71)| 00:00:19 |
|   1 |  SORT UNIQUE                  |           | 99587 |  2236K|  7088K|  1242  (71)| 00:00:19 |
|   2 |   UNION-ALL                   |           |       |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID| ORDERS    | 29914 |   671K|       |   184   (3)| 00:00:03 |
|*  4 |     INDEX RANGE SCAN          | PK_ORDERS | 29914 |       |       |    61   (4)| 00:00:01 |
|   5 |    TABLE ACCESS BY INDEX ROWID| ORDERS    | 69673 |  1564K|       |   424   (3)| 00:00:07 |
|*  6 |     INDEX RANGE SCAN          | PK_ORDERS | 69673 |       |       |   139   (4)| 00:00:03 |
Predicate Information (identified by operation id):
   4 - access("ID">600000 AND "ID"<630000)
   6 - access("ID">=630000)
Statistics
          0  recursive calls
          0  db block gets
        594  consistent gets
          0  physical reads
          0  redo size
    3353061  bytes sent via SQL*Net to client
      73711  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
     100000  rows processed
SQL>Even though the same number of rows is selected, and the same number of bytes are sent to the client, why is the number of logical IOs so much lower?
When I change the UNION to a UNION ALL the consistent gets go way up (13893) which I don't understand as well (the execution plan is basically the same, just missing the SORT UNIQUE node)
Can anyone shed some light on this? Especially why the UNION needs substantially less IO
I would have expected it to use more IO due to the duplicate index range scan. More like the figures I get when using UNION ALL
This is on a developer machine. Windows XP, Oracle 10.2.0.1.0
Thanks in advance
Thomas

Answer 1

Thanks for the answer.
Yes, the statistics are up-to-date.
Yes I have noticed the full table scan, but when I change the condition for the first select in order to reduce the number of rows so that an index range scan makes sense, the figures are more or less the same:
SQL> select * from orders where id > 630000;
70000 rows selected.
Execution Plan
Plan hash value: 1270478249
| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |           | 69672 |  1564K|   424   (3)| 00:00:07 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ORDERS    | 69672 |  1564K|   424   (3)| 00:00:07 |
|*  2 |   INDEX RANGE SCAN          | PK_ORDERS | 69672 |       |   139   (4)| 00:00:03 |
Predicate Information (identified by operation id):
   2 - access("ID">630000)
Statistics
          0  recursive calls
          0  db block gets
       9724  consistent gets
          0  physical reads
          0  redo size
    2627301  bytes sent via SQL*Net to client
      51711  bytes received via SQL*Net from client
       4668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      70000  rows processedWhen I change the condition for the union to only retrieve 70000 rows as well, I get figures comparable to my very first example:
SQL> select * from orders where id > 630000 and id < 650000 union select * from orders where id >= 650000;
70000 rows selected.
Execution Plan
Plan hash value: 2377290594
| Id  | Operation                     | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |           | 69673 |  1564K|       |   871  (73)| 00:00:13 |
|   1 |  SORT UNIQUE                  |           | 69673 |  1564K|  4977K|   871  (73)| 00:00:13 |
|   2 |   UNION-ALL                   |           |       |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID| ORDERS    | 19943 |   447K|       |   123   (3)| 00:00:02 |
|*  4 |     INDEX RANGE SCAN          | PK_ORDERS | 19943 |       |       |    42   (5)| 00:00:01 |
|   5 |    TABLE ACCESS BY INDEX ROWID| ORDERS    | 49730 |  1116K|       |   303   (3)| 00:00:05 |
|*  6 |     INDEX RANGE SCAN          | PK_ORDERS | 49730 |       |       |   100   (4)| 00:00:02 |
Predicate Information (identified by operation id):
   4 - access("ID">630000 AND "ID"<650000)
   6 - access("ID">=650000)
Statistics
          1  recursive calls
          0  db block gets
        418  consistent gets
          0  physical reads
          0  redo size
    2347358  bytes sent via SQL*Net to client
      51711  bytes received via SQL*Net from client
       4668  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
      70000  rows processed