ORA-14763: Unable to resolve FOR VALUES clause to a partition number

Question

I have partitioned my table on daily basis.

TABLE NAME MY_TABLE COLUMN NAME IN_TIME TIMESTAMP

I want to fetch the rows for the last 2 days partition. I am

Answer 1

Bind variables work for values but cannot be used to dynamically select an object, such as a table, view, or partition. Use the bind variable in a condition, and hope for partition pruning, or create a string for each query.

The bind variable limitation makes sense when you think about it. Parsing a query can be hard work - checking security, building an execution plan, etc. Using bind variables lets Oracle re-use most of the work when the next query comes in with only a different literal. But if the table name is different then it has to throw out all that work and completely re-parse the statement. So there's no benefit to bind variables in that situation.

With partitions it seems like there could be a benefit. Partitions are just parts of tables. The privileges don't change, so it seems like Oracle could potentially save some work by allowing bind variables there. However there are some objects that could be different for partitions. For example, it's possible to create an index that only exists on some of the partitions. In that case, an execution plan for one partition may not work for another.

(You could still make a case that bind variable partition names could be useful. Oracle has some dynamic execution plan features, like FILTER operations and adaptive re-optimization. So it could create a smart plan that adapts to different partitions. But it doesn't.)

Luckily partition pruning usually works just as well as specifying the partition value. Changing a query to this should run just as fast:

select * from my_table where some_date > trunc(:date_2_days_ago);

But using partitions implies retrieving a large percent of rows from the table. In that case, the query parse time might be irrelevant. If a query takes a minute to process, does it really matter if query parsing time takes 0.02 seconds instead of 0.01 seconds? If that's the case then the hard-coded SQL statement will work just as well.