Re: [HACKERS] Add support for tuple routing to foreign partitions - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: [HACKERS] Add support for tuple routing to foreign partitions
Date
Msg-id 5AC22188.9080106@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] Add support for tuple routing to foreign partitions  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [HACKERS] Add support for tuple routing to foreign partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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


pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Diagonal storage model
Next
From: Etsuro Fujita
Date:
Subject: Re: [HACKERS] Add support for tuple routing to foreign partitions