Re: [HACKERS] 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: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Stephen Frost <sfrost@snowman.net>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
Maksim Milyutin <milyutinma@gmail.com>,
Robert Haas <robertmhaas@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-04-03T13:04:33Z
Lists: pgsql-hackers
(2018/04/03 13:59), Amit Langote wrote: > On 2018/04/02 21:29, Etsuro Fujita wrote: >> (2018/04/02 18:49), Amit Langote wrote: >>> I looked at the new patch. It looks good overall, although I have one >>> question -- IIUC, BeginForeignInsert() performs actions that are >>> equivalent of performing PlanForeignModify() + BeginForeignModify() for an >>> INSERT as if it was directly executed on a given foreign table/partition. >>> Did you face any problems in doing the latter itself in the core code? >>> Doing it that way would mean no changes to a FDW itself will be required >>> (and hence no need for additional APIs), but I may be missing something. >> >> The biggest issue in performing PlanForeignModify() plus >> BeginForeignModify() instead of the new FDW API would be: can the core >> code create a valid-looking planner state passed to PlanForeignModify() >> such as the ModifyTable plan node or the query tree stored in PlannerInfo? > > Hmm, I can see the point. Passing mostly-dummy (garbage) PlannerInfo and > query tree from the core code to FDW seems bad. By defining the new API > with a clean interface (receiving fully valid ModifyTableState), we're not > required to do that across the interface, but only inside the FDW's > implementation. I really think so too. > I was just slightly concerned that the new FDW function > would have to implement what would normally be carried out across multiple > special purpose callbacks, but maybe that's OK as long as it's clearly > documented what its job is. OK > Noticed a couple of things in the patch: > > +<para> > + When this is called by a<command>COPY FROM</command> command, the > + plan-related global data in<literal>mtstate</literal> is not provided > + and the<literal>planSlot</literal> parameter of > +<function>ExecForeignInsert</function> called for each inserted > tuple is > > How about s/called/subsequently called/g? Done. > +<literal>NULL</literal>, wether the foreign table is the partition > chosen > > Typo: s/wether/whether/g Done. Thanks again, Amit! 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