@@ -970,20 +970,14 @@ get_partition_dispatch_recurse(Relation rel, Relation parent,
970
970
* partitions are processed as well and a corresponding PartitionDispatch
971
971
* object gets added to *pds.
972
972
*
973
- * About the values in pd->indexes: for a leaf partition, it contains the
974
- * leaf partition's position in the global list *leaf_part_oids minus 1,
975
- * whereas for a partitioned table partition, it contains the partition's
976
- * position in the global list *pds multiplied by -1. The latter is
977
- * multiplied by -1 to distinguish partitioned tables from leaf partitions
978
- * when going through the values in pd->indexes. So, for example, when
979
- * using it during tuple-routing, encountering a value >= 0 means we found
980
- * a leaf partition. It is immediately returned as the index in the array
981
- * of ResultRelInfos of all the leaf partitions, using which we insert the
982
- * tuple into that leaf partition. A negative value means we found a
983
- * partitioned table. The value multiplied by -1 is returned as the index
984
- * in the array of PartitionDispatch objects of all partitioned tables in
985
- * the tree. This value is used to continue the search in the next level
986
- * of the partition tree.
973
+ * The 'indexes' array is used when searching for a partition matching a
974
+ * given tuple. The actual value we store here depends on whether the
975
+ * array element belongs to a leaf partition or a subpartitioned table.
976
+ * For leaf partitions we store the 0-based index into *leaf_part_oids,
977
+ * and for sub-partitioned tables we store a negative version of the
978
+ * 1-based index into the *pds list. When searching, if we see a negative
979
+ * value, the search must continue in the corresponding sub-partition;
980
+ * otherwise, we've identified the correct partition.
987
981
*/
988
982
pd -> indexes = (int * ) palloc (partdesc -> nparts * sizeof (int ));
989
983
for (i = 0 ; i < partdesc -> nparts ; i ++ )
0 commit comments