Mohamed Houri’s Oracle Notes

December 24, 2013

Dynamic Partition Pruning

Filed under: Partitioning — hourim @ 10:50 am

A recent question on otn forum prompted me to write few words about dynamic pruning. Dynamic pruning occurs when Oracle knows that it will accomplish a partition pruning (elimination) but is unable to identify, at parse time, the partitions it has to eliminate. It has to wait until the query run time to find which partitions it will prune. This is represented in the execution plan via the word KEY in the PSTART (the first scanned partition) and PSTOP (the last scanned partition). So every time you see the word (KEY) in an execution plan, this is the CBO telling you that it is going to eliminate partitions but it will do that only during the query execution time. In this article I will try to show you few examples where dynamic pruning occurs.
The first and most evident situation of dynamic pruning is when you compare the partition key to a function which, in the CBO perception, it might return different results when called at parse time and at execution time. Here below a simple example

 create table t_range
    (
      id           number              not null,
      x            varchar2(30 char)   not null
    )
    partition by range (id)
    (
     partition p_10000 values less than (10000) ,
     partition p_20000 values less than (20000) ,
     partition p_30000 values less than (30000) ,
     partition p_40000 values less than (40000) ,
     partition p_50000 values less than (50000) ,
     partition p_60000 values less than (60000)
   );

insert into t_range values (150, 'First Part');
insert into t_range values (11500, 'Second Part');
insert into t_range values (25000, 'Third Part');
insert into t_range values (34000, 'Fourt Part');
insert into t_range values (44000, 'Fifth Part');
insert into t_range values (53000, 'Sixth Part');
commit;
exec dbms_stats.gather_table_stats (user, 't_range');

In the first next query I am going to compare the partition key (id) to a known and fixed value (150) while in the second query I will be comparing the same partition key to a variable value (trunc(dbms_random.value(150,150))) as perceived by the CBO.


SQL> explain plan for
    select *
    from t_range
    where id = 150 ;

--------------------------------------------------------------------------
| Id  | Operation              | Name    | Rows  | Bytes | Pstart| Pstop |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |         |     1 |    15 |       |       |
|   1 |  PARTITION RANGE SINGLE|         |     1 |    15 |     1 |     1 | --> first partition
|*  2 |   TABLE ACCESS FULL    | T_RANGE |     1 |    15 |     1 |     1 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ID"=150)

SQL> explain plan for
    select *
    from t_range
    where id = trunc(dbms_random.value(150,150)) ;

--------------------------------------------------------------------------
| Id  | Operation              | Name    | Rows  | Bytes | Pstart| Pstop |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |         |     1 |    15 |       |       |
|   1 |  PARTITION RANGE SINGLE|         |     1 |    15 |   KEY |   KEY | --> dynamic partition pruning
|*  2 |   TABLE ACCESS FULL    | T_RANGE |     1 |    15 |   KEY |   KEY |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("ID"=TRUNC("DBMS_RANDOM"."VALUE"(150,150)))

When I compared the partition key to a ”parse time unknown value then the CBO delayed the partition pruning at run time and materialized this dynamic pruning by the word KEY in the execution plan.

A more indicative and clear example is when you use a date range partitioned table and compare the partition key to the SYSDATE value.


drop table t_range;

create table t_range (id number, create_date date, rec_type varchar2(2))
partition by range (create_date)
(
 partition p1 values less than (to_date('01/01/2012','DD/MM/YYYY'))
,partition p2 values less than (to_date('01/02/2012','DD/MM/YYYY'))
,partition p3 values less than (to_date('01/03/2012','DD/MM/YYYY'))
,partition p4 values less than (to_date('01/04/2012','DD/MM/YYYY'))
,partition p5 values less than (to_date('31/12/2013','DD/MM/YYYY'))
);

insert into t_range values (1,to_date('01/01/2012', 'DD/MM/YYYY'),'RR');
insert into t_range values (2,to_date('05/03/2012', 'DD/MM/YYYY'),'RR');
insert into t_range values (3,to_date('03/02/2012', 'DD/MM/YYYY'),'RR');
insert into t_range values (4,to_date('03/02/2012', 'DD/MM/YYYY'),'ZZ');
insert into t_range values (5,to_date('06/03/2012', 'DD/MM/YYYY'),'ZZ');
insert into t_range values (6,to_date('18/03/2012', 'DD/MM/YYYY'),'WE');
insert into t_range values (7,to_date('15/01/2012', 'DD/MM/YYYY'),'ZZ');
insert into t_range values (8,to_date('24/12/2013', 'DD/MM/YYYY'),'ER');

commit;

exec dbms_stats.gather_table_stats (user, 't_range');

explain plan for
select * from t_range
where create_date = sysdate;

--------------------------------------------------------------------------
| Id  | Operation              | Name    | Rows  | Bytes | Pstart| Pstop |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |         |     1 |    14 |       |       |
|   1 |  PARTITION RANGE SINGLE|         |     1 |    14 |   KEY |   KEY | --> dynamic pruning with sysdate
|*  2 |   TABLE ACCESS FULL    | T_RANGE |     1 |    14 |   KEY |   KEY | --> because sysdate is a function
-------------------------------------------------------------------------- --> its value changes continuously with time

Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("CREATE_DATE"=SYSDATE@!)

explain plan for
select * from t_range
where create_date = to_date('24-12-2013','dd-mm-yyyy');

--------------------------------------------------------------------------
| Id  | Operation              | Name    | Rows  | Bytes | Pstart| Pstop |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |         |     1 |    14 |       |       |
|   1 |  PARTITION RANGE SINGLE|         |     1 |    14 |     5 |     5 |--> partition elimination occured
|*  2 |   TABLE ACCESS FULL    | T_RANGE |     1 |    14 |     5 |     5 |--  when sysdate has not been used
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("CREATE_DATE"=TO_DATE(' 2013-12-24 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

SYSDATE, in contrast to the current day, which is “24-12-2013″,  is continuously changing during time. Even though that we are interested only in the date part of the  SYSDATE value, the CBO still has to wait until the query execution time to find and eliminate the untouched partitions.

There is another situation where dynamic pruning might occur; it is when the partitioned table is joined to another table using the partition key and the CBO detects that there will be partition pruning because the joined table will not join all the partitions. In the next example I will create a t_join table in which I will insert all t_range ”partition keys”

create table t_join (id number, date_rec date, vc varchar2(30));

insert into t_join values (1,to_date('01/01/2012', 'DD/MM/YYYY'),'RR');
insert into t_join values (2,to_date('05/03/2012', 'DD/MM/YYYY'),'RR');
insert into t_join values (3,to_date('03/02/2012', 'DD/MM/YYYY'),'RR');
insert into t_join values (4,to_date('03/02/2012', 'DD/MM/YYYY'),'ZZ');
insert into t_join values (5,to_date('06/03/2012', 'DD/MM/YYYY'),'ZZ');
insert into t_join values (6,to_date('18/03/2012', 'DD/MM/YYYY'),'WE');
insert into t_join values (7,to_date('15/01/2012', 'DD/MM/YYYY'),'ZZ');
insert into t_join values (8,to_date('24/12/2013', 'DD/MM/YYYY'),'ER');
commit;

explain plan for
select *
from t_range a, t_join b
where
a.create_date = b.date_rec;

------------------------------------------------------------------------
| Id  | Operation            | Name    | Rows  | Bytes | Pstart| Pstop |
------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |         |     9 |   882 |       |       |
|*  1 |  HASH JOIN           |         |     9 |   882 |       |       |
|   2 |   PARTITION RANGE ALL|         |     8 |   112 |     1 |     5 |
|   3 |    TABLE ACCESS FULL | T_RANGE |     8 |   112 |     1 |     5 |
|   4 |   TABLE ACCESS FULL  | T_JOIN  |     8 |   672 |       |       |
------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("A"."CREATE_DATE"="B"."DATE_REC")

In this case the CBO determines, at parse time, that all partitions will be scanned and hence decided to scan all partitions (operation 2) at parse time. But what if I add a filter operation that eliminates few records?

explain plan for
select *
from t_range a, t_join b
where
a.create_date = b.date_rec
and b.id = 7;

-----------------------------------------------------------------------------
| Id  | Operation                 | Name    | Rows  | Bytes | Pstart| Pstop |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |         |     1 |    98 |       |       |
|   1 |  NESTED LOOPS             |         |     1 |    98 |       |       |
|*  2 |   TABLE ACCESS FULL       | T_JOIN  |     1 |    84 |       |       |
|   3 |   PARTITION RANGE ITERATOR|         |     1 |    14 |   KEY |   KEY |
|*  4 |    TABLE ACCESS FULL      | T_RANGE |     1 |    14 |   KEY |   KEY |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("B"."ID"=7)
4 - filter("A"."CREATE_DATE"="B"."DATE_REC")

Thanks to this additional filter on the t_join table , the CBO knows at parse time that it has to eliminate partitions. But as far as it has to wait until run time to apply the filter (predicate n° 2) then it is only at that time when it will be able to isolate the accessed partitions and eliminate the rest: this is dynamic pruning.

The next article will deal about partition pruning with hash partitioned tables.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Tony's Oracle Tips

Tony Hasler's light hearted approach to learning about Oracle

Richard Foote's Oracle Blog

Focusing Specifically On Oracle Indexes, Database Administration and Some Great Music

Hatem Mahmoud Oracle's blog

Just another Oracle blog : Database topics and techniques

Mohamed Houri’s Oracle Notes

Qui se conçoit bien s’énonce clairement

Oracle Diagnostician

Performance troubleshooting as exact science

Raheel's Blog

Things I have learnt as Oracle DBA

Coskan's Approach to Oracle

What I learned about Oracle

So Many Oracle Manuals, So Little Time

“Books to the ceiling, Books to the sky, My pile of books is a mile high. How I love them! How I need them! I'll have a long beard by the time I read them”—Lobel, Arnold. Whiskers and Rhymes. William Morrow & Co, 1988.

EU Careers info

Your career in the European Union

Carlos Sierra's Tools and Tips

Tools and Tips for Oracle Performance and SQL Tuning

Oracle Scratchpad

Just another Oracle weblog

OraStory

Dominic Brooks on Oracle Performance, Tuning, Data Quality & Sensible Design ... (Now with added Sets Appeal)

%d bloggers like this: