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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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