On 2017/08/26 1:43, Robert Haas wrote:
> On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
>>> I agree, but I wonder if we ought to make it work first using the
>>> existing APIs and then add these new APIs as an optimization.
>>
>> I'm not sure that's a good idea because that once we support INSERT
>> tuple-routing for foreign partitions, we would have a workaround: INSERT
>> INTO partitioned_table SELECT * from data_table where data_table is a
>> foreign table defined for an input file using file_fdw.
>
> That's true, but I don't see how it refutes the point I was trying to raise.
My concern is: the existing APIs can really work well for any FDW to do
COPY tuple-routing? I know the original version of the patch showed the
existing APIs would work well for postgres_fdw but nothing beyond. For
example: the original version made a dummy Query/Plan only containing a
leaf partition as its result relation, and passed it to
PlanForeignModify, IIRC. That would work well for postgres_fdw because
it doesn't look at the Query/Plan except the result relation, but might
not for other FDWs that look at more stuff of the given Query/Plan and
do something based on that information. Some FDW might check to see
whether the Plan is to do INSERT .. VALUES with a single VALUES sublist
or INSERT .. VALUES with multiple VALUES sublists, for optimizing remote
INSERT, for example.
Best regards,
Etsuro Fujita