Re: Run-time pruning for ModifyTable

Hi David,

On Thu, Jun 27, 2019 at 2:28 PM David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> Deja vu from this time last year when despite everyone's best efforts
> (mostly Alvaro) we missed getting run-time pruning in for MergeAppend
> into the PG11 release. This year it was ModifyTable, which is now
> possible thanks to Amit and Tom's modifications to the inheritance
> planner.
>
> I've attached what I have so far for this.

Thanks for working on this. IIUC, the feature is to skip modifying a
given result relation if run-time pruning dictates that none of its
existing rows will match some dynamically computable quals.

> I think it's mostly okay,
> but my brain was overheating a bit at the inheritance_planner changes.

I think we need to consider the fact that there is a proposal [1] to
get rid of inheritance_planner() as the way of planning UPDATE/DELETEs
on inheritance trees. If we go that route, then a given partitioned
target table will be expanded at the bottom and so, there's no need
for ModifyTable to have its own run-time pruning info, because
Append/MergeAppend will have it. Maybe, we will need some code in
ExecInitModifyTable() and ExecModifyTable() to handle the case where
run-time pruning, during plan tree initialization and plan tree
execution respectively, may have rendered modifying a given result
relation unnecessary.

A cursory look at the patch suggests that most of its changes will be
for nothing if [1] materializes. What do you think about that?

Thanks,
Amit

[1] https://www.postgresql.org/message-id/357.1550612935%40sss.pgh.pa.us