On Fri, Jan 12, 2018 at 12:23 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote: >> (1) if they need it by subplan index, first use >> subplan_partition_offsets to convert it to a per-leaf index > > Before that, we need to check if there *is* an offset array. If there > are no partitions, there is only going to be a per-subplan array, > there won't be an offsets array. But I guess, you are saying : "do the > on-demand allocation only for leaf partitions; if there are no > partitions, the per-subplan maps will always be allocated for each of > the subplans from the beginning" . So if there is no offset array, > just return mtstate->mt_per_subplan_tupconv_maps[subplan_index] > without any further checks.
Oops. I forgot that there might not be partitions. I was assuming that mt_per_subplan_tupconv_maps wouldn't exist at all, and we'd always use subplan_partition_offsets. Both that won't work in the inheritance case. > But after that, I am not sure then why is mt_per_sub_plan_maps[] array > needed ? We are always going to convert the subplan index into leaf > index, so per-subplan map array will not come into picture. Or are you > saying, it will be allocated and used only when there are no > partitions ? From one of your earlier replies, you did mention about > trying to share the maps between the two arrays, that means you were > considering both arrays being used at the same time. We'd use them both at the same time if we didn't have, or didn't use, subplan_partition_offsets, but if we have subplan_partition_offsets and can use it then we don't need mt_per_sub_plan_maps. I guess I'm inclined to keep mt_per_sub_plan_maps for the case where there are no partitions, but not use it when partitions are present. What do you think about that? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
