Oracle 10g:MIN/MAX kolomwaarde schatting

Ja, LOW_VALUE en HIGH_VALUE geven de minimum- en maximumwaarden aan in de kolom maar :

• ze worden opgeslagen als RAW(32)-kolommen, dus de betekenis zal niet meteen duidelijk zijn
• ze zijn van de laatste keer dat er statistieken voor de tabel zijn verzameld, dus zijn ze mogelijk niet nauwkeurig (tenzij je expliciet statistieken verzamelt voordat je ze gebruikt)

Als u de kolom indexeert, moeten MIN(a) en MAX(a) erg snel zijn, zoals in dit voorbeeld, waar T1 50000 rijen heeft en wordt geïndexeerd op OBJECT_ID:

SQL> select min(object_id) from t1;

MIN(OBJECT_ID)
--------------
           100

------------------------------------------------------------------------------------
| Id  | Operation                  | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |       |     1 |     5 |     2   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE            |       |     1 |     5 |            |          |
|   2 |   INDEX FULL SCAN (MIN/MAX)| T1_ID | 53191 |   259K|     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        419  bytes sent via SQL*Net to client
        380  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

Het resultaat is hetzelfde als u de MAX selecteert in plaats van de MIN. Als u echter de MIN en MAX selecteert in een enkele select-opdracht, is het resultaat anders:

SQL> select min(object_id), max(object_id) from t1;

MIN(OBJECT_ID) MAX(OBJECT_ID)
-------------- --------------
           100          72809


-------------------------------------------------------------------------------
| Id  | Operation             | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |       |     1 |     5 |    34   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE       |       |     1 |     5 |            |          |
|   2 |   INDEX FAST FULL SCAN| T1_ID | 53191 |   259K|    34   (0)| 00:00:01 |
-------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        125  consistent gets
          0  physical reads
          0  redo size
        486  bytes sent via SQL*Net to client
        380  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

Dit suggereert dat het misschien beter is om ze apart te krijgen, hoewel ik dat niet overtuigend heb bewezen.