I wrote: > I think what we have to do basically is repeat what fill_extraUpdatedCols > does independently for each target table. That's not really horrible: > given the premise that we're moving this calculation into the planner, > we can have expand_single_inheritance_child run the code while we have > each target table open. It'll require some rethinking though, and we > will need to have the set of update target columns already available > at that point. This suggests that we want to put the updated_cols and > extraUpdatedCols fields into RelOptInfo not PlannerInfo.
After further thought: maybe we should get radical and postpone this work all the way to executor startup. The downside of that is having to do it over again on each execution of a prepared plan. But the upside is that when the UPDATE targets a many-partitioned table, we would have a chance at not doing the work at all for partitions that get pruned at runtime. I'm not sure if that win would emerge immediately or if we still have executor work to do to manage pruning of the target table. I'm also not sure that this'd be a net win overall. But it seems worth considering. regards, tom lane