Re: Run-time pruning for ModifyTable

On Tue, Apr 7, 2020 at 8:52 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> 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.

That's correct, although I don't think Append/MergeAppend will need to
look any different structurally, except its subnodes will need to
produce a targetlist member to identify partition/child for a given
output row. There will still be N result relations, but not the N
plans created separately for each, as inheritance_planner() currently
does.

> > 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.

That makes sense. I am thinking to spend some time working on this
early in PG 14 cycle.

--
Thank you,

Amit Langote
EnterpriseDB: http://www.enterprisedb.com