On 2016/03/10 19:51, Robert Haas wrote:
On Wed, Mar 9, 2016 at 3:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Robert Haas <robertmh...@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

I agree with Robert.

Best regards,
Etsuro Fujita

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to