Each partition has its own segments. So the database physically stores the rows for each in separate locations. Assuming you need to access the table, you have to read all the relevant partitions.
So no, you can't "ignore" or bypass partitioning.
And there's no way to unpartition a table either. You'll have to recreate it, which is best done with dbms_redefinition.
Or you could just merge the partitions together:
create table t (
c1, c2, c3, c4
) partition by range ( c1 ) (
partition p0 values less than ( 10 ),
partition p1 values less than ( 20 ),
partition p2 values less than ( 30 ),
partition p3 values less than ( 40 ),
partition p4 values less than ( 50 )
) as
select level c1, sysdate + level c2 ,
round ( dbms_random.value ( 1, 100 ) ) c3,
dbms_random.string ( 'a', 20 ) c4
from dual
connect by level < 50;
alter table t
merge partitions p0, p1, p2, p3, p4
into partition p4;
select partition_name
from user_tab_partitions
where table_name = 'T';
PARTITION_NAME
P4
Of course, query performance is just one reason for partitioning. There are many other reasons to use it, such as:
- Fast & easy data archival via
drop/truncate partition
- Fast data loads with
exchange partition
- Stopping people changing old data by marking partitions as
read only
- Storing older data on slower (cheaper) disk
- ...
So it's worth checking that you're not making use of other partitioning features before wiping them out.
That said, ~200k rows/partition and 25M total does seem a little on the small side to be worth partitioning to me.
Technically, there is another option...
business users query on this table with queries that, apart from
filter values, are always the same.
Are these aggregation (count, sum, avg, etc. ) queries? e.g.:
select customer_id, count(*)
from ...
where ...
group by customer_id
If so materialized views (MVs) may be a good option to "bypass" partitioning.
create materialized view mv as
select customer_id, count(*)
from ...
where ...
group by customer_id
You can partition (or not) these in a different way to the base tables. With added the advantage that if your queries typically process "many" rows but return "few", using the MV could be much faster.
select/*+ NO_PARALLEL*/ * fromor decrease the level of parallelismselect/*+ PARALLEL 2 */ * from. - Dmitry Demin