Re: Add support for tuple routing to foreign partitions

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>

From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Date: 2017-09-01T06:30:36Z
Lists: pgsql-hackers
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



Commits

  1. Allow insert and update tuple routing and COPY for foreign tables.

  2. Refactor PgFdwModifyState creation/destruction into separate functions.