Thank you for sharing the formula. That formula is either very close or exactly right – I cannot tell at the moment because I am showing that the table in this database contains 16217 blocks, which based on the formula you provided, suggests that the actual number of blocks in the original test table should be about 16,378 (this is possible, but I cannot check right now).

For those that decide to test the values shown for the fetch array size of 1, keep in mind that the article states: “As you can see from the above, when the fetch array size was set to 1, SQL*Plus actually operated as if the fetch array size was set to 2.”

Thank you for contributing to the article.

consistent gets are more or less equal to the formula below for a single full table scan (depends on the tablespace management is auto or manual )

(NUM_ROWS / ARRAYSIZE)+NUM_BLOCKS.

Like Tom Kyte and “>Vivek Sharma explained

I am not sure if it can be formulated for joins but it is nice to know the formula

Thanks for contributing your test case in this blog article. It is interesting that removing the unique contraint affects the execution plan.

My test showed that there was only about a 7 second time difference between the fetch array size of 200 and the fetch array size of 2000 (01:29.87 – 01:22.25) on Oracle 11.2.0.1. On Oracle 11.1.0.6 the difference was only about 2.5 seconds (01:24.48 – 01:21.96). I noticed that my times were a bit faster than were your times – I wonder if network performance might be a limiting factor that causes your execution time to level off with a fetch array size of 200. If the client computer was also the server computer (no network involved) it could be that you reached the server’s memory throughput/transfers per second threshold.

I am not sure what the correct answer is for your question. The answer might depend on the execution plan – whether there are nested loop joins, hash joins, etc. By reviewing my summarized test case output, the number of consistent gets perform continued to decrease as the array fetch size increased.

You might take a look at the comment made in this thread by Jonathan Lewis:
http://forums.oracle.com/forums/thread.jspa?threadID=973560&start=0&tstart=0
“If the query really is nothing but a UNION ALL of five tablescans, then what it the array fetch size ? If the array fetch size is large enough the number of block visits would be similar to the number of physical block reads. If the arraysize is one then the number of block visits could be close to the number of rows fetched as a block has to be released at the end of each fetch and the reacquired for the next fetch.”

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000K|   105M|  2717   (2)| 00:00:39 |
|*  1 |  TABLE ACCESS FULL| T5   |  1000K|   105M|  2717   (2)| 00:00:39 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("T51"."C1">='A 0000000' AND "T51"."C1"
 
alter table t5 drop constraint SYS_C00807645;

obtain the following execution plan .. hint applies when
the constraint no longer exists ….identical to what you got with version 11.1.0.6 ….

---------------------------------------------------------------------------------
| Id  | Operation                | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |      |  1000K|   846M|    19G  (2)|999:59:59 |
|   1 |  NESTED LOOPS            |      |  1000K|   846M|    19G  (2)|999:59:59 |
|   2 |   NESTED LOOPS           |      |  1000K|   741M|    16G  (2)|999:59:59 |
|   3 |    NESTED LOOPS          |      |  1000K|   635M|    13G  (2)|999:59:59 |
|   4 |     NESTED LOOPS         |      |  1000K|   529M|    10G  (2)|999:59:59 |
|   5 |      NESTED LOOPS        |      |  1000K|   423M|  8145M  (2)|999:59:59 |
|   6 |       NESTED LOOPS       |      |  1000K|   317M|  5430M  (2)|999:59:59 |
|   7 |        NESTED LOOPS      |      |  1000K|   211M|  2715M  (2)|999:59:59 |
|*  8 |         TABLE ACCESS FULL| T5   |  1000K|   105M|  2717   (2)| 00:00:39 |
|*  9 |         TABLE ACCESS FULL| T5   |     1 |   111 |  2715   (2)| 00:00:39 |
|* 10 |        TABLE ACCESS FULL | T5   |     1 |   111 |  2715   (2)| 00:00:39 |
|* 11 |       TABLE ACCESS FULL  | T5   |     1 |   111 |  2715   (2)| 00:00:39 |
|* 12 |      TABLE ACCESS FULL   | T5   |     1 |   111 |  2715   (2)| 00:00:39 |
|* 13 |     TABLE ACCESS FULL    | T5   |     1 |   111 |  2715   (2)| 00:00:39 |
|* 14 |    TABLE ACCESS FULL     | T5   |     1 |   111 |  2715   (2)| 00:00:39 |
|* 15 |   TABLE ACCESS FULL      | T5   |     1 |   111 |  2715   (2)| 00:00:39 |
---------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   8 - filter("T51"."C1">='A 0000000' AND "T51"."C1"='A 0000000' AND "T52"."C1"='A 0000000' AND "T53"."C1"='A 0000000' AND "T54"."C1"='A 0000000' AND "T55"."C1"='A 0000000' AND "T56"."C1"='A 0000000' AND "T57"."C1"='A 0000000' AND "T58"."C1"<='A 1000000' AND
              "T51"."C1"="T58"."C1")

I would like to ask a question instead on logical reads.
I re-run your tests twice, the first with ArraySize default (if I remember correctly is equal to 15) and the second ArraySize 200.

select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

With arraysize 15 (default)


Elapsed: 00:14:41.71

Statistiche
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      74776  consistent gets
          0  physical reads
          0  redo size
   89664222  bytes sent via SQL*Net to client
     466899  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

With arraysize 200

Elapsed: 00:02:52.76

Statistiche
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      13118  consistent gets
          0  physical reads
          0  redo size
   86271849  bytes sent via SQL*Net to client
      35230  bytes received via SQL*Net from client
       5001  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

whereas in tests carried my table has the following features:….

select num_rows, blocks, trunc(num_rows/blocks) row_for_block 
from user_tables
where table_name = 'T5';

  NUM_ROWS     BLOCKS     ROW_FOR_BLOCK
---------- ---------- -------------
   1000000       8107           123

I do not get significant benefits by increasing further ArraySize(in my case 200), in fact if I set arraysize at a number greater than the number of rows stored in Each single table blocks, the number of logical reads is close to the number of the table's
blocks… right?

Thanks a lot

Regards

Donatello Settembrino

Thanks for providing the link – I agree, his case #2 explains very clearly what happened during my test run on 11.2.0.1. I thought that the feature was called table elimination (where a parent table could be eliminated if a foreign key constraint is present and no columns from the parent are returned), but the 10053 trace shows that it is correctly referred to as join elimination.

It is impressive to see that this join elimination works with self joins, but I wonder if it would still work if there were different WHERE clause predicates for each of the aliases – for instance an EMPLOYEES table that lists the employee’s supervisor in one column, so a self join would be needed to determine for all of the employees, which employees they supervise. It might be something interesting to explore.

Maybe I’d get used to it if I was using 11gR2 as a primary platform.

Thanks for stopping by and providing a comment. I was thinking the same thing regarding the changes to the ARRAYSIZE setting. My Faulty Quotes blog article about the buffer cache hit ratio metric references this document and this OTN thread where Jonathan Lewis described how Oracle is able to grab a block and pin it when the fetch array size is increased, thus reducing the consistent gets statistic.

When I first saw Oracle 11.2.0.1′s consistent gets statistic for this query, I immediately thought that maybe Oracle 11.2.0.1 had greatly improved the block pinning behavior. I was surprise, shocked, maybe even a little impressed when I saw that the 8 way self-join was collapsed into a single full table scan.