Fujita-san,
On Wed, Jun 24, 2026 at 6:15 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Wed, Jun 24, 2026 at 1:25 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > On Wed, Jun 24, 2026 at 11:23 AM Richard Guo <guofenglinux@gmail.com> wrote:
> > > On Wed, Jun 24, 2026 at 10:43 AM Amit Langote <amitlangote09@gmail.com> wrote:
> > > > If we’d rather avoid it, I have a no-field alternative for REL_18: show_modifytable_info() is the only reader
ofthe re-indexed list, and it can recompute the mapping from node->resultRelations and node->fdwPrivLists, both
plan-orderedand untouched by pruning.
> > >
> > > This sounds like a nice solution. Since show_modifytable_info() is
> > > only used for EXPLAIN, I guess the recompute overhead on the
> > > re-indexed list should be fine.
> >
> > Thanks for chiming in, here is the patch to do so.
>
> Thanks for the patch!
>
> + /*
> + * node->fdwPrivLists is indexed by the original, pre-pruning
> + * result relation order and is parallel to node->resultRelations.
> + * Initial pruning may have dropped earlier relations, so the kept
> + * index j need not match the original position; find this
> + * relation's entry by its range table index instead.
> + */
> + forboth(lc1, node->resultRelations, lc2, node->fdwPrivLists)
> + {
> + if (lfirst_int(lc1) == (int) rti)
> + {
> + fdw_private = (List *) lfirst(lc2);
> + break;
> + }
> + }
>
> I think it's good to skip this for efficiency, when there are no
> pruned result relations.
Thanks for the review. v2 attached implements your suggestion: it
indexes node->fdwPrivLists directly with j when no result relations
were pruned, and only falls back to matching by range table index when
pruning appears to have dropped some.
> Other than that the patch looks good to me.
>
> I didn't know pg_rewrite's use of ModifyTableState, which was
> different than I expected. Sorry for that.
No need to apologize at all. Tom's point about it was new to me too.
I will push v2 to REL_18 tomorrow barring objections.
--
Thanks, Amit Langote
