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.
- For the case where the primary index column set does not contain the complete partitioning column set, specifying an equality join on the primary index column set, but not on the partitioning column set. It is better for there to be fewer partitions after any row partition elimination, and the fewer partitions that remain, the better.
- The Optimizer can specify a sliding window join when there is a small number of partitions; otherwise, the table might 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.
- Note that the Optimizer does not know whether a partition is unpopulated or populated, so it 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.