The plan doesn't use the index but the cost of INDEX FULL SCAN looks better

Question

Hi,
Well, I'm sure I miss the boat... and if the question is pretty tricky, the answer is probably :"You're stupid Greg!". Well anyway, you'll probably be interested in trying to answer it as I've spent some times on it without any result ! I use Oracle XE on Windows...
1) Below is my query and its plan. You'll find the full schema generation script at the end of this email. Look at the cost (468) of the plan and the cost of the same query when you force the use of the index (116). Why is this ?
select count(distinct col5)
  2    from demo
  3      where col1 between 1 and 50000
  4        and col2=col1
  5        and col3=col1
  6        and col4=col1;
Plan d'execution
Plan hash value: 2072716547
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   116 |   468   (2)| 00:00:06 |
|   1 |  SORT GROUP BY     |      |     1 |   116 |            |          |
|*  2 |   TABLE ACCESS FULL| DEMO |     1 |   116 |   468   (2)| 00:00:06 |
Predicate Information (identified by operation id):
   2 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=50000 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)2) When I force the use of an index (with a Hint), You'll see the cost of the plan is 116 which is definitly better than the TABLE ACCESS FULL (468) :
SQL> l
  1  select /*+ index(demo demo_idx)*/ count(distinct col5)
  2    from demo
  3      where col1 between 1 and 50000
  4        and col2=col1
  5        and col3=col1
  6*       and col4=col1
SQL> /
Plan d'execution
Plan hash value: 189561699
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |          |     1 |   116 |   437   (2)| 00:00:06 |
|   1 |  SORT GROUP BY               |          |     1 |   116 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEMO     |     1 |   116 |   437   (2)| 00:00:06 |
|*  3 |    INDEX FULL SCAN           | DEMO_IDX |     1 |       |   436   (2)| 00:00:06 |
Predicate Information (identified by operation id):
   3 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=50000 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)3) My question is why is plan1 used while plan2 should be considered better by the optimizer regarding the cost (to make the case even more complex, plan1 is actually more efficient but this is out of the scope of my question. I know that and I know why !).
You'll find a script to generate the structures and data below. I can send you the 10053 traces if you what to go furthermore. Take care the index is a REVERSE index (Don't know if query rewrite should be enabled in order to take advantage of this type of index but it is set to "true" (and "trusted") :
drop table demo;
create table demo (col1 number not null,
    col2 number,
    col3 number,
    col4 number,
    col5 varchar2(500));
begin
  for i in 1..100000 loop
    insert into demo values (i,i,i,i,'This column is used to raise the High Water Mark and '||
                             ' the cost of an TABLE ACCESS FULL operation');
  end loop;
end;
commit;
create index demo_idx on demo(col1,col2,col3,col4) reverse;
exec dbms_stats.gather_table_stats(USER, 'DEMO', cascade=>true, -
  method_opt=>'FOR ALL COLUMNS SIZE 254', no_invalidate=>false) Any comments are welcome ! Best Regards,
Gregory
Message was edited by:
arkzoyd... I've added the "pre" tags

Answer 1

I suspect this has something to do with db_file_multiblock_read_count
After running provided creation statements by you I got following results:
SQL> show parameter multiblock
NAME                                 TYPE        VALUE
db_file_multiblock_read_count        integer     16
SQL> set autotrace on
SQL> select count(distinct col5)
  2   from demo
  3   where col1 between 1 and 50000
  4   and col2=col1
  5   and col3=col1
  6   and col4=col1
  7  /
COUNT(DISTINCTCOL5)
                  1
Execution Plan
Plan hash value: 2072716547
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   116 |   375   (1)| 00:00:05 |
|   1 |  SORT GROUP BY     |      |     1 |   116 |            |          |
|*  2 |   TABLE ACCESS FULL| DEMO |     1 |   116 |   375   (1)| 00:00:05 |
Predicate Information (identified by operation id):
   2 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
0 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
Statistics
        196  recursive calls
          0  db block gets
       1734  consistent gets
        850  physical reads
          0  redo size
        422  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          7  sorts (memory)
          0  sorts (disk)
          1  rows processed
SQL> select /*+ index(demo demo_idx)*/ count(distinct col5)
  2   from demo
  3   where col1 between 1 and 50000
  4   and col2=col1
  5   and col3=col1
  6   and col4=col1
  7  /
COUNT(DISTINCTCOL5)
                  1
Execution Plan
Plan hash value: 189561699
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT             |          |     1 |   116 |   431   (1)| 0
0:00:06 |
|   1 |  SORT GROUP BY               |          |     1 |   116 |            |
        |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEMO     |     1 |   116 |   431   (1)| 0
0:00:06 |
|*  3 |    INDEX FULL SCAN           | DEMO_IDX |     1 |       |   430   (1)| 0
0:00:06 |
Predicate Information (identified by operation id):
   3 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
0 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
Statistics
          1  recursive calls
          0  db block gets
      50426  consistent gets
        428  physical reads
          0  redo size
        422  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processedNow I modify multiblock_read_count and full scan cost is going up although anyway Oracle by default chooses full scan instead of index access.
SQL> alter session set db_file_multiblock_read_count = 8;
Session altered.
SQL> select count(distinct col5)
  2   from demo
  3   where col1 between 1 and 50000
  4   and col2=col1
  5   and col3=col1
  6   and col4=col1
  7  /
COUNT(DISTINCTCOL5)
                  1
Execution Plan
Plan hash value: 2072716547
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |      |     1 |   116 |   463   (1)| 00:00:06 |
|   1 |  SORT GROUP BY     |      |     1 |   116 |            |          |
|*  2 |   TABLE ACCESS FULL| DEMO |     1 |   116 |   463   (1)| 00:00:06 |
Predicate Information (identified by operation id):
   2 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
0 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
Statistics
          1  recursive calls
          0  db block gets
       1697  consistent gets
        850  physical reads
          0  redo size
        422  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed
SQL> select /*+ index(demo demo_idx)*/ count(distinct col5)
  2   from demo
  3   where col1 between 1 and 50000
  4   and col2=col1
  5   and col3=col1
  6   and col4=col1
  7  /
COUNT(DISTINCTCOL5)
                  1
Execution Plan
Plan hash value: 189561699
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| T
ime     |
|   0 | SELECT STATEMENT             |          |     1 |   116 |   431   (1)| 0
0:00:06 |
|   1 |  SORT GROUP BY               |          |     1 |   116 |            |
        |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEMO     |     1 |   116 |   431   (1)| 0
0:00:06 |
|*  3 |    INDEX FULL SCAN           | DEMO_IDX |     1 |       |   430   (1)| 0
0:00:06 |
Predicate Information (identified by operation id):
   3 - filter("COL2"="COL1" AND "COL3"="COL1" AND "COL4"="COL1" AND
              "COL1"<=50000 AND "COL2"<=50000 AND "COL3"<=50000 AND "COL4"<=5000
0 AND
              "COL1">=1 AND "COL2">=1 AND "COL3">=1 AND "COL4">=1)
Statistics
          1  recursive calls
          0  db block gets
      50426  consistent gets
          0  physical reads
          0  redo size
        422  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processedSo I don't know what is the default value of dbfmbrc in XE and not gone too deep to understand how for example system statistics may change your situation.
Gints Plivna
http://www.gplivna.eu
P.S. BTW I used Oracle Database 10g Enterprise Edition Release 10.2.0.1.0.
Message was edited by:
gintsp
listened to Williams suggestion :)