Partioning spatially indexed tables

Question

I am a complete novice when it comes to partitioning, so can someone tell me any advantages/disadvantages/problems in partitioning a large RTREE spatially indexed table (using an SDO_GEOMETRY column) containing several million rows?

Answer 1

Just to make sure you understand what is and isn't possible:
When partitioning a table with spatial data, you cannot partition based on the geometry column.
Spatial index partitioning is only available on a table that has been partitioned by range.
All of the manageability benefits associated with partitioning data applies to data with a spatial column as well. If the index has been built using partitioning, you can do things like store different index partitions in different tablespaces, index partition rebuilds, index partition archives, exchange, split, merge partitions, etc.
In terms of performance, there are several benefits that can be achieved:
If the partition key can be specified as a predicate on the query, then there can be a large performance improvement.
If you can't specify a partition key in the query, then if the index is stored across different tablespaces then concurrency can improve if multiple sessions are accessing the index.
Single stream performance can be improved through the use of parallelism as well.
Most of the above is available in 9iR1, although exchange partition and parallelism both were available as of 9iR2.
If there is no parallelism, and no partition key predicate can be specified in spatial queries, and there is only single session access to the database, and you don't need the manageability benefits, then partitioning probably isn't for you.