Follow these guidelines whenever possible when you are formulating join conditions for your queries against PPI tables.
- If possible, specify join conditions with an equality join on the primary index column set and partitioning column set.
This type of join condition uses an efficient, rowkey-based merge join.
- Consider adding the partitioning column for the PPI table to the other table in the join.
- If the primary index column set does not contain the complete partitioning column set, consider specifying an equality join on the primary index column set, but not on the partitioning column set.
The fewer partitions that remain after any row partition elimination, the better.
- The Optimizer can specify a sliding window join when there is a small number of partitions. Otherwise, the table may need to be spooled and sorted.
- Use RANGE_N to define fewer partitions for the table.
- Specify join conditions on the partitioning columns to influence the Optimizer to use row partition elimination to reduce the number of partitions involved in the join.
- The Optimizer does not know whether a partition is unpopulated or populated, and assumes that all defined partitions are populated with rows.
PARTITION statistics help the Optimizer to estimate the cost of join plans, but the join plan selected by the Optimizer cannot assume that partitions are unpopulated.