(2017/12/18 18:14), Amit Langote wrote:
> I noticed that this patch introduces a partition_rels field in
> ModifyTable, which contains the RT indexes of *all* leaf partitions in the
> partition tree. That means we now expand the partition inheritance tree
> in the planner even in the INSERT case, simply because some of the leaf
> partitions might be foreign tables which must be looked at by the planner.
Yeah, the patch expands the inheritance tree at planning time as well to
build an RTE for each partition so that the FDW can use that RTE eg,
when called from PlanForeignModify.
> I'm somewhat concerned about the performance implications of that. Now,
> to insert even a single row into a partitioned table, which may not even
> be routed to any of its foreign partitions, we are going to have to expand
> the inheritance twice -- once by the planner to handle foreign partitions
> and then by the executor when setting up the tuple routing information.
>
> Is there any reason why we have to to things this way, beside the fact
> that the PlanForeignModify() API appears to be callable from only within a
> valid planner context?
Another reason for that is for set_plan_references to get such RTEs to
record plan dependencies so that plancache.c invalidates cached plans
for foreign partitions.
I suspect that we could avoid the planning-time expansion by doing some
optimization when inserting a single row into a partitioned table.
Best regards,
Etsuro Fujita