Re: partition routing layering in nodeModifyTable.c

On Wed, Oct 14, 2020 at 6:04 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> On 14/10/2020 09:44, Amit Langote wrote:
> > I like the idea of storing the ResultRelInfo in ForeignScanState, but
> > it would be better if we can document the fact that an FDW may not
> > reliably access until IterateDirectModify(). That's because, setting
> > it in ExecInitForeignScan() will mean *all* result relations must be
> > initialized during ExecInitModifyTable(), which defies my
> > lazy-ResultRelInfo-initiailization proposal. As to why why I'm
> > pushing that proposal, consider that when we'll get the ability to use
> > run-time pruning for UPDATE/DELETE with [1], initializing all result
> > relations before initializing the plan tree will mean most of those
> > ResultRelInfos will be unused, because run-time pruning that occurs
> > when the plan tree is initialized (and/or when it is executed) may
> > eliminate most but a few result relations.
> >
> > I've attached a diff to v17-0001 to show one way of delaying setting
> > ForeignScanState.resultRelInfo.
>
> The BeginDirectModify function does a lot of expensive things, like
> opening a connection to the remote server. If we want to optimize
> run-time pruning, I think we need to avoid calling BeginDirectModify for
> pruned partitions altogether.

Note that if foreign partitions get pruned during the so called "init"
run-time pruning (that is, in the ExecInitNode() phase),
BeginDirectModify() won't get called on them. Although, your concern
does apply if there is only going to be "exec" run-time pruning and no
"initial" pruning.

For me, the former case is a bit more interesting, as it occurs with
prepared statements using a generic plan (update parted_table set ...
where partkey = $1).

> I pushed this without those delay-setting-resultRelInfo changes. But we
> can revisit those changes with the run-time pruning optimization patch.

Sure, that makes sense.

> I'll continue with the last couple of patches in this thread.

Okay, thanks.

--
Amit Langote
EDB: http://www.enterprisedb.com