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

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Stephen Frost <sfrost(at)snowman(dot)net>, Maksim Milyutin <milyutinma(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Add support for tuple routing to foreign partitions
Date: 2018-04-02 12:26:48
Message-ID: 5AC22188.9080106@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2018/03/30 22:28), Alvaro Herrera wrote:
> Etsuro Fujita wrote:
>
>> Now we have ON CONFLICT for partitioned tables, which requires the
>> conversion map to be computed in ExecInitPartitionInfo, so I updated the
>> patch so that we keep the former step in ExecInitPartitionInfo and
>> ExecSetupPartitionTupleRouting and so that we just init the FDW in
>> ExecInitExtraPartitionInfo (changed to ExecInitForeignRouting). And I added
>> comments to ExecInitForeignRouting and ExecPrepareTupleRouting.
>
> Hmm, I may be misreading what you mean here ... but as far as I
> understand, ON CONFLICT does not support foreign tables, does it?

It doesn't, except for ON CONFLICT DO NOTHING without an inference
specification.

> If
> that is so, I'm not sure why the conversion map would be necessary, if
> it is for ON CONFLICT alone.

We wouldn't need that for foreign partitions (When DO NOTHING with an
inference specification or DO UPDATE on a partitioned table containing
foreign partitions, the planner would throw an error before we get to
ExecInitPartitionInfo). The reason why I updated the patch that way is
just to make the patch simple, but on reflection I don't think that's a
good idea; I think we should delay the map-creation step as well as the
FDW-initialization step for UPDATE subplan partitions as before for
improved efficiency for UPDATE-of-partition-key. However, I don't think
it'd still be a good idea to delay those steps for partitions created by
ExecInitPartitionInfo the same way as for the subplan partitions,
because in that case it'd be better to perform CheckValidResultRel
against a partition right after we do InitResultRelInfo for the
partition in ExecInitPartitionInfo, as that would save cycles in cases
when the partition is considered nonvalid by that check. So, What I'm
thinking is: a) for the subplan partitions, we delay those steps as
before, and b) for the partitions created by ExecInitPartitionInfo, we
do that check for a partition right after InitResultRelInfo in that
function, (and if valid, we create a map and initialize the FDW for the
partition in that function).

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2018-04-02 12:29:11 Re: [HACKERS] Add support for tuple routing to foreign partitions
Previous Message Andrey Borodin 2018-04-02 12:21:13 Re: Diagonal storage model