Re: Add support for tuple routing to foreign partitions

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: Add support for tuple routing to foreign partitions
Date: 2017-09-01 06:30:36
Message-ID: 983b9afe-fc04-5f60-d036-dc8d3e544e78@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017/08/26 1:43, Robert Haas wrote:
> On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-09-01 06:38:04 Re: pgbench: Skipping the creating primary keys after initialization
Previous Message Simon Riggs 2017-09-01 06:25:16 Re: Surjective functional indexes