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