On Wed, Oct 14, 2020 at 6:04 PM Heikki Linnakangas <hlinn...@iki.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
