Index is not being used on a partitioned table - database

Question

I have tableA, which is (list) partitioned almost evenly by 5 values. tableA contains 100million rows and has a local (partitioned) index on customFunc(x). Following query does RANGE SCAN using mentioned index and takes about 5-10s to execute and returns 5million.
select count(*) from tableA where customFunc(x)='abc';
Unfortunately, when I try to execute the same query on a specific partition it does full table scan and takes forever..
select count(*) from tableA where customFunc(x)='abc' and partitioning_key='DT';
I completely don't understand why it works that way.. Shouldn't it take an advantage of partition pruning in the 2nd case?
EDIT: Adding a hint /*+ index(tableA mentionedIndex) */ solves the problem, but I still don't understand why it is not used by default
EDIT: XPLAN 1
Plan hash value: xxx
---------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 17 | 29335 (1)| 00:00:02 | | |
| 1 | SORT AGGREGATE | | 1 | 17 | | | | |
| 2 | PARTITION LIST ALL| | 5227K| 84M| 29335 (1)| 00:00:02 | 1 | 5 |
|* 3 | INDEX RANGE SCAN | CUSTOM_FUNC_INDEX | 5227K| 84M| 29335 (1)| 00:00:02 | 1 | 5 |
---------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access(customFunc(x)='abc')
XPLAN 2 (with partition key)
Plan hash value: yyy
----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 30 | 679K (2)| 00:00:27 | | |
| 1 | SORT AGGREGATE | | 1 | 30 | | | | |
| 2 | PARTITION LIST SINGLE| | 4014K| 114M| 679K (2)| 00:00:27 | KEY | KEY |
|* 3 | TABLE ACCESS FULL | tableA | 4014K| 114M| 679K (2)| 00:00:27 | 1 | 1 |
----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter(customFunc(x)='abc')

Answer 1

Shouldn't it take an advantage of partition pruning in the 2nd case?
The second query does apply partition pruning: that's what this step means: PARTITION LIST SINGLE . The catch is that partition pruning means reading the whole partition: in the second plan the step TABLE ACCESS FULL means read all the rows in the partition, don't use an index. Consequently, the second query is evaluating customFunc(x)='abc' for every row in the partition.
What is the point of creating a local index with partitioning key?
The difference is that a local index prefixed with the partitioning key will always use partition pruning, whereas when a local index doesn't have the partitioning key the optimiser can choose whether to apply partition pruning. But if you want to run queries that don't use the partition key then clearly you need the non-prefixed version.
Now you're right to be puzzled. Given the partition key as a predicate the optimizer ought to have executed an INDEX RANGE SCAN against the indicated partition. To figure out why it doesn't will require more effort on your part. It may be that your statistics are stale or you need to gather histograms. Maybe the fact that it's a function-based index confuses the optimizer. If you have the access, or a co-operative DBA, you can use the 10053 event to look under the hood. Find out more.