How to utilize table partition in oracle database in effective manner?

Question

I have created a partitioned table as

CREATE TABLE orders_range(order_id NUMBER 
                         ,client_id NUMBER 
                         ,order_date DATE) 
  PARTITION BY RANGE(order_date) 
    (PARTITION orders2011 VALUES LESS THAN (to_date('1/1/2012','dd/mm/yyyy')) 
    ,PARTITION orders2012 VALUES LESS THAN (to_date('1/1/2013','dd/mm/yyyy')) 
    ,PARTITION orders2013 VALUES LESS THAN (MAXVALUE));

when I am selecting the records using

SELECT * FROM ORDERS_RANGE partition(orders2011);

in explain plan the cpu cost is 75 but when i go for normal query using where clause the cpu cost is only 6 then what is the advantage of table partitioning when it comes to performance? Can anyone explain me in detail?

Thanks in advance.

Answer 1

First, you generally can't directly compare the cost of two different plans running against two different objects. It is entirely possible that one plan with a cost of 10,000 will run much more quickly than a different plan with a cost of 10. You can compare the cost of two different plans for a single SQL statement within a single 10053 trace (so long as you remember that these are estimates and if the optimizer estimates incorrectly, many cost values are incorrect and the optimizer is likely to pick a less efficient plan). It may make sense to compare the cost between two different queries if you are trying to work out the algorithm the optimizer is using for a particular step but that's pretty unusual.

Second, in your example, you're not inserting any data. Generally, if you're going to partition a table, you're doing so because you have multiple GB of data in that table. If you compare something like

SELECT *
  FROM unpartitioned_table_with_1_billion_rows

vs

SELECT *
  FROM partitioned_table_with_1_billion_rows
 WHERE partition_key = date '2014-04-01' -- Restricts the data to only 10 million rows

the partitioned approach will, obviously, be more efficient not least of all because you're only reading the 10 million rows in the April 1 partition rather than the 1 billion rows in the table.

If the table has no data, it's possible that the query against the partitioned table would be a tiny bit less efficient since you've got to do more things in the course of parsing the query. But reading 0 rows from a 0 row table is going to take essentially no time either way so the difference in parse time is likely to be irrelevant.

In general, you wouldn't ever use the ORDERS_RANGE partition(orders2011) syntax to access data. In addition to hard-coding the partition name, which means that you'd often be resorting to dynamic SQL to assemble the query, you'd be doing a lot more hard parsing and that you'd be putting more pressure on the shared pool and that you'd risk making a mistake if someone changed the partitioning on the table. It makes far more sense to supply a predicate on the partition key and to let Oracle work out how to appropriately prune the partitions. In other words

SELECT *   
  FROM orders_range  
 WHERE order_date < date '2012-01-01'

would be a much more sensible query.