On Wed, Mar 9, 2016 at 3:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Mar 9, 2016 at 1:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I hadn't been paying any attention to this thread, but I wonder whether
>>> this entire approach isn't considerably inferior to what we can do now
>>> with the planner pathification patch. To quote from the new docs:
>
>> Well, I guess I'm not quite seeing it. What do you have in mind?
>> 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.
Like what?
>> 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?
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company