Horton

Re: [HACKERS] Add support for tuple routing to foreign partitions

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

View thread View on postgr.es
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Stephen Frost <sfrost@snowman.net>
Cc: 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>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Date: 2018-02-02T10:33:14Z
Lists: pgsql-hackers 
(2018/01/25 23:33), Stephen Frost wrote:
> I'm afraid a good bit of this patch is now failing to apply.  I don't
> have much else to say except to echo the performance concern that Amit
> Langote raised about expanding the inheritence tree twice.

To address that concern, I'm thinking to redesign the patch so that it 
wouldn't expand the tree at planning time anymore.  I don't have any 
clear solution for that yet, but what I have in mind now is to add new 
FDW APIs to the executor, instead, so that the FDW could 1) create stuff 
such as a query for remote INSERT as PlanForeignModify and 2) 
initialize/end the remote INSERT operation as BeginForeignModify and 
EndForeignModify, somewhere in the executor.  (For #1, I'm thinking to 
add an API for that to ExecSetupPartitionTupleRouting or 
ExecInitPartitionResultRelInfo proposed by the patch by Amit Langote 
[1].)  Anyway, I'll work on this after reviewing that patch, so I'll 
mark this as Returned with feedback.

Thanks for the comment!

Best regards,
Etsuro Fujita

[1] https://commitfest.postgresql.org/16/1415/

Commits

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

  2. Refactor PgFdwModifyState creation/destruction into separate functions.