Table partitioning enables one table to be divided into multiple self-contained sub-sections (partitions) that can be located in different physical areas. A row from a partitioned table never spans a partition boundary. Prior to OpenEdge 11.4, a table, regardless of size, was physically stored in only one storage area. It was also treated as a single unit at the application and database levels. Consequently, for a very large table, it could be very slow and costly to perform certain operations, either run-time queries or maintenance activities.
Partitioning tables can provide advantages, including the following:
Improved performance
If querying with a partition-aligned index, whole partitions can be quickly removed from consideration. This is called pruning.
Concurrency is increased in random activity.
Improved availability
Maintenance can be performed on a single partition, leaving other partitions from a table available.
Improved maintenance
Utilities can operate on one partition, reducing the amount of time that data is unavailable (locked by the utility). Partition maintenance includes partition management to split, merge and purge partitions; partition-level index management such as index check, fix and rebuild; and partition-level data activities such as binary dump and load.
Partitioning tables also has the risk associated with these disadvantages:
Correct partitioning requires knowledge of table layout and application deign to be aligned with the physical layout of the database. Re-partitioning is expensive, requiring a dump and load of data.
Updating a partition-aligned column can cause a row to be moved from one partition to another.
Improved performance