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
-
Allow insert and update tuple routing and COPY for foreign tables.
- 3d956d9562aa 11.0 landed
-
Refactor PgFdwModifyState creation/destruction into separate functions.
- 870d89608e5f 11.0 landed