On 2018/04/17 16:41, Etsuro Fujita wrote: > In the INSERT/COPY-tuple-routing case, as explained by Amit, the > RTE at that position in the EState's range table is the one for the > partitioned table of a given partition, so the statement would be true. > BUT in the UPDATE-tuple-routing case, the RTE is the one for the given > partition, not for the partitioned table, so the statement would not be > true. In the latter case, we don't need to create a child RTE and replace > the original RTE with it, but I handled both cases the same way for > simplicity.
Oh, I didn't really consider this part carefully. That the resultRelInfo received by BeginForeignInsert (when called by ExecInitRoutingInfo) could be a reused UPDATE result relation. It might be possible to justify the parent_rte/child_rte terminology by explaining it a bit better. I see three cases that arise during tuple routing: 1. This is INSERT and so the resultRelation that's received in BeginForeignInsert has been freshly created in ExecInitPartitionInfo and it bears node->nominalRelation or 1 as its ri_RangeTableIndex 2. This is UPDATE and the resultRelInfo that's received in BeginForeignInsert has been freshly created in ExecInitPartitionInfo and it bears node->nominalRelation or 1 as its ri_RangeTableIndex 3. This is UPDATE and the resultRelInfo that's received in BeginForeignInsert is a reused one, in which case, it bears the planner assigned ri_RangeTableIndex In all three cases, I think we can rely on using ri_RangeTableIndex to fetch a valid "parent" RTE from es_range_table. Do you think we need to clarify this in a comment? Thanks, Amit
