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.
I pushed this without those delay-setting-resultRelInfo changes. But we
can revisit those changes with the run-time pruning optimization patch.
I'll continue with the last couple of patches in this thread.
- Heikki
