Re: Run-time pruning for ModifyTable

On Wed, 25 Mar 2020 at 15:37, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> Actually, I was saying in that email that the update/delete planning
> overhaul being talked about will make the entirety of the
> functionality this patch is adding, which is ModifyTable node being
> able to prune its subplans based on run-time parameter values,
> redundant. That's because, with the overhaul, there won't be multiple
> subplans under ModifyTable, only one which would take care of any
> pruning that's necessary.

Thanks for explaining. I've not read over any patch for that yet, so
wasn't aware of exactly what was planned.

With your explanation, I imagine some sort of Append / MergeAppend
that runs the query as if it were a SELECT, but each
Append/MergeAppend subnode is tagged somehow with an index of which
ModifyTable subnode that it belongs to. Basically, just one complete
plan, rather than a plan per ModifyTable subnode.

> What I did say in favor of this patch though is that it doesn not seem
> that invasive, so maybe okay to get in for v13.

Since it seems there's much less code that will be useful after the
rewrite than I thought, combined with the fact that I'm not entirely
sure the best way to reuse the partitioned table's RelOptInfo from the
SELECT's PlannerInfo, then I'm going to return this one with feedback.

David