On Tue, Apr 7, 2020 at 8:52 PM David Rowley <dgrowle...@gmail.com> wrote: > On Wed, 25 Mar 2020 at 15:37, Amit Langote <amitlangot...@gmail.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
