What's wrong with the following result_cache hint?

Question

Dear all,
I try to use result_cache hint in the following sql aggregate function statement, but the explain plan doesn't show any difference between non-result_cached and with result_cached:
SQL> set autot on explain stat
SQL> select account_mgr_id,count(*) from customers group by account_mgr_id;
ACCOUNT_MGR_ID      COUNT(*)
        147            76
        149            74
        148            58
        145           111
Execution Plan
Plan hash value: 1577413243
| Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |            |     4 |    16 |     6     (17)| 00:00:01 |
|   1 |  HASH GROUP BY        |            |     4 |    16 |     6     (17)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| CUSTOMERS |   319 |  1276 |     5      (0)| 00:00:01 |
Statistics
       0  recursive calls
       0  db block gets
      16  consistent gets
       0  physical reads
       0  redo size
     689  bytes sent via SQL*Net to client
     524  bytes received via SQL*Net from client
       2  SQL*Net roundtrips to/from client
       0  sorts (memory)
       0  sorts (disk)
       4  rows processed
SQL> select /*+ result_cache */ account_mgr_id,count(*) from customers group by account_mgr_id;
ACCOUNT_MGR_ID      COUNT(*)
        147            76
        149            74
        148            58
        145           111
Execution Plan
Plan hash value: 1577413243
| Id  | Operation         | Name                | Rows  | Bytes | Cost (%CPU)| Time      |
|   0 | SELECT STATEMENT    |                     |     4 |    16 |     6  (17)| 00:00:01 |
|   1 |  RESULT CACHE         | 3s3bugtq0p5bm71mhmqvvw0x7y |      |      |           |       |
|   2 |   HASH GROUP BY     |                     |     4 |    16 |     6  (17)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| CUSTOMERS            |   319 |  1276 |     5   (0)| 00:00:01 |
Result Cache Information (identified by operation id):
   1 - column-count=2; dependencies=(OE.CUSTOMERS); name="select /*+ result_cache */ account_mgr_id,
count(*) from customers group by account_mgr_id"
Statistics
       1  recursive calls
       0  db block gets
      16  consistent gets
       0  physical reads
       0  redo size
     689  bytes sent via SQL*Net to client
     524  bytes received via SQL*Net from client
       2  SQL*Net roundtrips to/from client
       0  sorts (memory)
       0  sorts (disk)
       4  rows processedAnything wrong with the hint?
Best regards,
Val

Answer 1

Two executions required to benefit from result cache (two executions of the statement with the result cache hint).
First to populate, Second to benefit.
Can offer good benefits particularly with poor code - e.g. functions in SQL, row-by-row function calls, etc.
Optimal solution may be to refactor to more efficient approach.
But result cache can deliver significant short term tactical gain.
Not a no-brainer though.
There were scalability issues with a single latch protecting the result cache - I believe this has changed in 11gR2.
There are also issues with concurrent executions were the result needs to be recalculated and takes x time to regenerate that result.
See http://uhesse.wordpress.com/2009/11/27/result-cache-another-brilliant-11g-new-feature/#comment-216
SQL> drop table t1;
Table dropped.
SQL>
SQL> create table t1
  2  as
  3  select rownum col1
  4  from   dual
  5  connect by rownum <= 100000;
Table created.
SQL> set autotrace traceonly explain statistics
SQL> select col1
  2  from   t1
  3  where  col1 >= 99997;
Execution Plan
Plan hash value: 3617692013
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |      |    10 |   130 |    58   (9)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T1   |    10 |   130 |    58   (9)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1">=99997)
Note
   - dynamic sampling used for this statement (level=4)
Statistics
         10  recursive calls
          0  db block gets
        220  consistent gets
        153  physical reads
          0  redo size
        379  bytes sent via SQL*Net to client
        334  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed
SQL> select col1
  2  from   t1
  3  where  col1 >= 99997;
Execution Plan
Plan hash value: 3617692013
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |      |    10 |   130 |    58   (9)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T1   |    10 |   130 |    58   (9)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1">=99997)
Note
   - dynamic sampling used for this statement (level=4)
Statistics
          0  recursive calls
          0  db block gets
        158  consistent gets
          0  physical reads
          0  redo size
        379  bytes sent via SQL*Net to client
        334  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed
SQL>
SQL>
SQL> select /*+ result_cache */ col1
  2  from   t1
  3  where  col1 >= 99997;
Execution Plan
Plan hash value: 3617692013
| Id  | Operation          | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |                            |    10 |   130 |    58   (9)| 00:00:01 |
|   1 |  RESULT CACHE      | 4p777jcbdgjm25xy3502ypdb5r |       |       |            |          |
|*  2 |   TABLE ACCESS FULL| T1                         |    10 |   130 |    58   (9)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("COL1">=99997)
Result Cache Information (identified by operation id):
   1 - column-count=1; dependencies=(RIMS.T1); name="select /*+ result_cache */ col1
from   t1
where  col1 >= 99997"
Note
   - dynamic sampling used for this statement (level=4)
Statistics
          4  recursive calls
          0  db block gets
        216  consistent gets
          0  physical reads
          0  redo size
        379  bytes sent via SQL*Net to client
        334  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed
SQL>
SQL>
SQL> select /*+ result_cache */ col1
  2  from   t1
  3  where  col1 >= 99997;
Execution Plan
Plan hash value: 3617692013
| Id  | Operation          | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |                            |    10 |   130 |    58   (9)| 00:00:01 |
|   1 |  RESULT CACHE      | 4p777jcbdgjm25xy3502ypdb5r |       |       |            |          |
|*  2 |   TABLE ACCESS FULL| T1                         |    10 |   130 |    58   (9)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("COL1">=99997)
Result Cache Information (identified by operation id):
   1 - column-count=1; dependencies=(RIMS.T1); name="select /*+ result_cache */ col1
from   t1
where  col1 >= 99997"
Note
   - dynamic sampling used for this statement (level=4)
Statistics
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        379  bytes sent via SQL*Net to client
        334  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed
SQL>