Re: partition routing layering in nodeModifyTable.c
От | Andres Freund |
---|---|
Тема | Re: partition routing layering in nodeModifyTable.c |
Дата | |
Msg-id | 20190731153556.il5vdwyiwsjdpz3z@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: partition routing layering in nodeModifyTable.c (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: