Sorry I didn’t put another comment earlier but I didn’t get your post via email ( I think I checked the box !!! weird ).

Anyway… our database is 10.2.0.4 and I finally solved the issue adding a hint with the name of the index :

SELECT …
FROM …
WHERE …
and … IN (SELECT /*+ index(pp FBI)*/…
FROM … PP
WHERE … );

That approach is much better than the hint “cursor_sharing_exact” for our needs.

Bertran.

The fact that the index doesn’t work in the subquery example may be nothing to do with the setting for cursor_sharing, and may depend on other transformations taking place. In the absence of any information about the version of Oracle, the actual execution plan, and the actual use of predicates, it’s impossible to come to any conclusion.

I think I have a similar issue. I created a FBI which is used when queried “directly” but not when used in an IN clause. Maybe this is due to the optimizer not taking into account that index for some reason.

Example :

Select …
From some_table
Where translate(some_column,’0123…abc…ABC…’,’0123′)=’123′;

That case works even using cs similar, but this other doesn’t :

Select …
From some_join
Where filter column in ( select_from_prior_example );

This case doesn’t take FBI into account unless I add the hint :

Select /*+ cursor_sharing_exact */…
From some_join
Where filter column in ( select_from_prior_example );

I have tried your view approach bu didn’t work.

Can you shed some light on this ?

Thanks,
Bertran.

Sometimes you get a good idea by going back and looking again at something you’ve done in the past and asking yourself if there’s a (possibly new) alternative. Your comment here, for example, prompted me to think of the “obvious” new solution – if you’re running 11g you just declare a virtual column to match the substr() requirement and create an index on the virtual column (remembering to collect stats on the virtual column, of course) then modify the code accordingly.

After I created the index I queried the user_tab_cols view.

jbrock@orcl10g-local> select column_name, num_distinct, hidden_column,virtual_column
2 from user_tab_cols where table_name = ‘T1′;

COLUMN_NAME NUM_DISTINCT HID VIR
—————————— ———— — —
ID NO NO
VC1 NO NO
PADDING NO NO
SYS_NC00004$ YES YES

Appears Oracle creates a hidden/virtual column for FBIs.
NUM_DISTINCT is null because I haven’t gathered stats.

jbrock@orcl10g-local> begin
2 dbms_stats.gather_table_stats(
3 ownname => user,
4 tabname =>’T1′,
5 estimate_percent => 100,
6 method_opt => ‘for all hidden columns size 1′
7 );
8 end;
9 /

For FBIs I usually used the ‘hidden columns’ trick I learned from Richard Foote’s seminar.

Now I rerun the user_tab_cols query again.

jbrock@orcl10g-local> select column_name, num_distinct, hidden_column,virtual_column
2 from user_tab_cols where table_name = ‘T1′;

COLUMN_NAME NUM_DISTINCT HID VIR
—————————— ———— — —
ID NO NO
VC1 NO NO
PADDING NO NO
SYS_NC00004$ 676 YES YES

Now that it can see some values I continue with the script you posted and got the following execution plan.

alter session set statistics_level=’all’;
select * from table(dbms_xplan.display_cursor);

—————————————————————————————
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————————
| 0 | SELECT STATEMENT | | | | 16 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 15 | 1710 | 16 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T1_FBI1 | 15 | | 1 (0)| 00:00:01 |
—————————————————————————————
Predicate Information (identified by operation id):
—————————————————
2 – access(“T1″.”SYS_NC00004$”=’zz’)