thanks for even more simpler test case.

So it seems to be special case code in the optimizer which covers the function with CASE or NVL2 + rowid and probably eliminates access path: index (IndexOnly). My previous example works fine (with no access table) on 10.2 and goes wrong on 11.1 and 11.2.

It might be so. Looks like the same “fix” was “ported” to 10.2.0.5 which also reports table access, while 10.2.0.4 does not.

drop table t purge;
create table t (id number not null, x number);
create index i on t(id, nvl(x,1));

explain plan for
select a
from (select 1 id from dual) t1
   , (select id, nvl(x,1) a from (select * from t)) t2
where t1.id = t2.id(+);
select * from table(dbms_xplan.display);

And in 11.2 I got NL2 instead of CASE in 10053.

SELECT NVL2("T".ROWID,NVL("T"."X",1),NULL) "A" FROM "SYS"."DUAL" "DUAL","TEST_USER"."T" "T" WHERE "T"."ID"(+)=1

thank you for feedback. I’ll post the complete 10053 trace and update the post probably today.

I’m afraid we have a bit of a miscommunication here. I did read your original post, and I understand it very well. But I would like to know the full details of this case. You didn’t post the entire 10053 trace, but claim that it is caused by case in the select statement. Being a longer time reader of your blog, I believe your diagnosis. But it is not sufficient enough for me to understand when and where this would happen. That is why I am asking for alternatives, to see what exactly goes on.

In your blog post you ask if somebody has seen this issue before. No, I don’t know the issue. If that was the only reason for your blog post, we’re done. But I’d prefer your blog to be a bit more substantial, and to make your readers understand what’s going on.

Just a thought.

Regards,

Arian

SQL> explain plan for
  2  select /*+ optimizer_features_enable('8.1.7') */ t2.y
  3    from (select 1 id from dual) t1
  4       , (select id, y from v2 where id = :1) t2
  5   where t1.id = t2.id(+);

Explained.

SQL> @xp

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------
Plan hash value: 250159355

--------------------------------------------------------------
| Id  | Operation           | Name   | Rows  | Bytes | Cost  |
--------------------------------------------------------------
|   0 | SELECT STATEMENT    |        |  1000 | 65000 |     2 |
|   1 |  MERGE JOIN OUTER   |        |  1000 | 65000 |     2 |
|   2 |   FAST DUAL         |        |     1 |       |     1 |
|   3 |   VIEW              |        |  1000 | 65000 |     1 |
|*  4 |    FILTER           |        |       |       |       |
|*  5 |     INDEX RANGE SCAN| T_INDX |  1000 | 13000 |     1 |
--------------------------------------------------------------

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

   4 - filter(TO_NUMBER(:1)=1)
   5 - access("T"."ID"=TO_NUMBER(:1))

Note
-----
   - cpu costing is off (consider enabling it)

22 rows selected.

SQL> explain plan for
  2  select /*+ optimizer_features_enable('9.0.0') */ t2.y
  3    from (select 1 id from dual) t1
  4       , (select id, y from v2 where id = :1) t2
  5   where t1.id = t2.id(+);

Explained.

SQL> @xp

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------
Plan hash value: 3556404565

-----------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost  |
-----------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     1 |    20 |     2 |
|   1 |  MERGE JOIN OUTER            |        |     1 |    20 |     2 |
|   2 |   FAST DUAL                  |        |     1 |       |     1 |
|   3 |   TABLE ACCESS BY INDEX ROWID| T      |     1 |    20 |     1 |
|*  4 |    INDEX RANGE SCAN          | T_INDX |     1 |       |     1 |
-----------------------------------------------------------------------

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

   4 - access("T"."ID"(+)=TO_NUMBER(:1))
       filter("T"."ID"(+)=1)

Note
-----
   - cpu costing is off (consider enabling it)

21 rows selected.

thanks for your desire to help to overcome the issue, but please read my reply about the purpose of this post.

But I wonder what happens when you put t2 in a with clause.

Originally it was there; it doesn’t change the way how original query behaves. However, the presence of the subquery factoring (which I don’t like; I will write a post on this some day) makes the fix dependent on the Oracle version in use. But, again – this isn’t my point here.

thanks. That’s an interesting development. But now you are materializing the view first. I don’t have a database at the moment. But I wonder what happens when you put t2 in a with clause.
Would Oracle still transform it to the same view? And if so, what happens when you add a materialize hint?

Regards,

Arian

I know I can do different things to get rid of this – but the point is to find out why CASE expression appears here, how this transformation is called and how to control it without query modification on Oracle parameters level.

You can make your example more simple, “group by” is redundant here. And I suggest you will not see CASE there.

thanks for comment. If you try to change a subquery by adding rownum like this:

explain plan for
select count(t2.y)
  from (select 1 id from dual) t1
     , (select id, y from v2 where id = :1 and rownum > 0) t2
 where t1.id = t2.id(+)
 group by t1.id;

You’ll see that Oracle is able to avoid table access. It’s still same query, same outer join – and yet no table access.

NVL is there just to apply a function, in reality there’s something different.

It makes sense to me.

In your first query, table T can be accessed by ID, which is the first column of the index. So the index range scan has a nice selectivity.
In your second query, you first have an outer join. This means you need all the ID values from t2. Then you count the data on t2.y. So the optimizer needs to decide the value of t2.y which is not a part of the index. So the table has to be read to check the predicate.

Since you are using an nvl in your view, it would make more sense to query count(t2.id). The result will be the same. Even though an outer join is out of place here anyway.

Regards,

Arian