Re: partition routing layering in nodeModifyTable.c

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