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
