Re: Add support for tuple routing to foreign partitions

On 2017/08/17 17:27, Etsuro Fujita wrote:
> On 2017/07/11 6:56, Robert Haas wrote:
>> I have to admit that I'm a little bit fuzzy about why foreign insert
>> routing requires all of these changes.  I think this patch would
>> benefit from being accompanied by several paragraphs of explanation
>> outlining the rationale for each part of the patch.
>
> Will do.

Here is an updated version of the patch.

* Query planning: the patch creates copies of Query/Plan with a foreign
partition as target from the original Query/Plan for each foreign
partition and invokes PlanForeignModify with those copies, to allow the
FDW to do query planning for remote INSERT with the existing API. To
make such Queries the similar way inheritance_planner does, I modified
transformInsertStmt so that the inh flag for the partitioned table's RTE
is set to true, which allows (1) expand_inherited_rtentry to build an
RTE and AppendRelInfo for each partition in the partitioned table and
(2) make_modifytable to build such Queries using adjust_appendrel_attrs
and those AppendRelInfos.

* explain.c: I modified show_modifytable_info so that we can show remote
queries for foreign partitions in EXPLAIN for INSERT into a partitioned
table the same way as for inherited UPDATE/DELETE cases. Here is an
example:

postgres=# explain verbose insert into pt values (1), (2);
QUERY PLAN
-------------------------------------------------------------------
Insert on public.pt (cost=0.00..0.03 rows=2 width=4)
Foreign Insert on public.fp1
Remote SQL: INSERT INTO public.t1(a) VALUES ($1)
Foreign Insert on public.fp2
Remote SQL: INSERT INTO public.t2(a) VALUES ($1)
-> Values Scan on "*VALUES*" (cost=0.00..0.03 rows=2 width=4)
Output: "*VALUES*".column1
(7 rows)

I think I should add more explanation about the patch, but I don't have
time today, so I'll write additional explanation in the next email.
Sorry about that.

Best regards,
Etsuro Fujita