From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, amitdkhan(dot)pg(at)gmail(dot)com |
Subject: | Re: partition routing layering in nodeModifyTable.c |
Date: | 2019-07-31 15:35:56 |
Message-ID: | 20190731153556.il5vdwyiwsjdpz3z@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-07-31 21:03:58 +0900, Etsuro Fujita wrote:
> I'm still not sure that it's a good idea to remove
> es_result_relation_info, but if I had to say then I think the latter
> would probably be better. I'm planning to rework on direct
> modification to base it on upper planner pathification so we can
> perform direct modification without the ModifyTable node. (I'm not
> sure we can really do this for inherited UPDATE/DELETE, though.) For
> that rewrite, I'm thinking to call BeginDirectModify() from the
> ForeignScan node (ie, ExecInitForeignScan()) as-is. The latter
> approach would allow that without any changes and avoid changing that
> API many times. That's the reason why I think the latter would
> probably be better.
I think if we did that, it'd become *more* urgent to remove
es_result_relation. Having more and more plan nodes change global
resources is a recipse for disaster.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-07-31 15:44:24 | Re: How to retain lesser paths at add_path()? |
Previous Message | Alvaro Herrera | 2019-07-31 15:23:22 | Re: Unused header file inclusion |