Re: Optimization for updating foreign tables in Postgres FDW

On 2016/03/10 19:51, Robert Haas wrote:
> On Wed, Mar 9, 2016 at 3:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Just taking a guess here, you might be thinking that instead of
>>> something like this...
>>
>>>    Update on public.ft2
>>>      ->  Foreign Update on public.ft2
>>
>>> We could boil it all the way down to this:
>>
>>>      Foreign Update on public.ft2
>>
>> Exactly.  I'm not claiming that that would be particularly faster, but
>> it would eliminate a whole bunch of seriously ugly stuff that's in
>> this patch.

>>> But can you, really?  What if the UPDATE is targeting an inheritance
>>> hierarchy containing some local tables and some remote tables?
>>
>> I don't really see why that couldn't be made to work.  You'd end up
>> with ForeignUpdates on the remote tables and a ModifyTable handling
>> the rest.
>
> I don't get it.  I mean, what's the parent node going to be?  If it's
> the ModifyTable, then the plan tree looks the same as what this
> already does.  If not, then what?

I don't get it, either.  If the ForeignUpdates would be executed 
separately from the ModifyTable, how would the query's reported row 
count (ie, estate->es_processed) be handled?

> Just to recap the history, this patch was rewritten, criticized by
> Stephen and you and rewritten to match your feedback.  Then, both of
> you ignored it for a long time while I and others but a lot of work
> into it.  Now, we're up against the deadline for this release and you
> don't like it again.  Well, OK.  If you want to rewrite it into some
> form you think is better, I'm cool with that.  But it would be really
> unfair if this slipped out of this release after so much work has been
> put into making it match the design ideas that *you* put forward just
> because, at the eleventh hour, you now have new ones.  Personally, I
> think we should just commit the darned thing and you can rewrite it
> later if you want.  If you want to rewrite it now instead, I can live
> with that, too.  But let's figure out how we're going to move this
> forward.

I agree with Robert.

Best regards,
Etsuro Fujita