Sorry, but:
- I do not understand what the aim of your query is
- The query does not containt an OR and, probably for that reason, to me it seems that such an execution plan cannot be generated based on the query you provided.

BTW, the PARTITION RANGE OR is a new kind of partition pruning that is available as of 11g. It is used when, in the WHERE clause, there are several restrictions on the partition key that are connected by an OR. Up to 10g such a query would lead to a FTS.

HTH
Chris

PS: I edited you comment to make it more readable

SELECT count(d)
FROM t
WHERE 
((
         d >= to_date('2009-12-01 01:00:00','yyyy-mm-dd hh24:mi:ss')
     and d = to_date('2009-12-01 05:00:00','yyyy-mm-dd hh24:mi:ss')
     and d <= to_date('2009-12-01 06:00:00','yyyy-mm-dd hh24:mi:ss')
));
    
| Id  | Operation           | Name | Pstart| Pstop |
----------------------------------------------------
|   0 | SELECT STATEMENT    |      |       |       |
|   1 |  SORT AGGREGATE     |      |       |       |
|   2 |   PARTITION RANGE OR|      |KEY(OR)|KEY(OR)|
|   3 |    TABLE ACCESS FULL| T    |KEY(OR)|KEY(OR)|
----------------------------------------------------

> could we still make slected index partitions unusable?

Yes

> if yes – what about the inserts? Can we still insert into the table partitions with usable index?

Yes and no. In fact, it is only possible to insert data in partitions that are not in unusable state.

Cheers,
Chris

– could we still make slected index partitions unusable?

– if yes – what about the inserts? Can we still insert into the table partitions with usable index?

Yes, table expansion is related to it. For example, when tracing the query optimizer work with event 10053 the information related to this feature is reported in the “sections” of table expansion (search for “TE:”). Among others, the query after the transformation is given.

About the limitation… As I wrote, in this specific case I was not able to make it generate a UNION ALL with three SELECTs. It might be that in other case it works… Honestly, I didn’t spent much time on it. But, again, in this case it doesn’t work and, IMO, there is no good reason for it. In fact, when I run the query with the following ranges it works as expected:
- 2009-10-30 23:00:00 – 2009-11-30 23:59:59
- 2009-11-01 00:00:00 – 2009-12-01 01:00:00
Also from a cost point of view it makes no sense what the query optimizer do. In fact, in this case, the index range scan costs 2 and the full partition scan costs 68. When table expansion happens, the total cost is simply the sum of the two (70). However, when I run the query covering three partitions the resulting cost is 200! So, much higher than 2+68+2 ;-)

Anyway, in practice I don’t think that this limitation will be relevant.

Cheers,
Chris

This behavior seems to controlled by the new hidden parameter “_optimizer_table_expansion”. Table expansion makes it possible to expand the predicates spanning multiple partitions into the UNION ALL version of the query.

And my simple test case showed that the table expansion works with no problem even with the middle local index partition disabled. Your case would be the result of cost based query transformation which would have determined that expanded query is more costly.

Cheers.