Re: partition routing layering in nodeModifyTable.c
От | Amit Langote |
---|---|
Тема | Re: partition routing layering in nodeModifyTable.c |
Дата | |
Msg-id | CA+HiwqG9gNOC8yAiJoo4xsavmq+Xe2ru97r=KMwu9gMOMt-csQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: partition routing layering in nodeModifyTable.c (Amit Langote <amitlangote09@gmail.com>) |
Список | pgsql-hackers |
On Wed, Oct 28, 2020 at 4:46 PM Amit Langote <amitlangote09@gmail.com> wrote: > > On Tue, Oct 27, 2020 at 10:23 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > > This patch looks reasonable to me at a quick glance. I'm a bit worried > > or unhappy about the impact on FDWs, though. It doesn't seem nice that > > the ResultRelInfo is not available in the BeginDirectModify call. It's > > not too bad, the FDW can call ExecGetResultRelation() if it needs it, > > but still. Perhaps it would be better to delay calling > > BeginDirectModify() until the first modification is performed, to avoid > > any initialization overhead there, like establishing the connection in > > postgres_fdw. > > Ah, calling BeginDirectModify() itself lazily sounds like a good idea; > see attached updated 0001 to see how that looks. While updating that > patch, I realized that the ForeignScan.resultRelation that we > introduced in 178f2d560d will now be totally useless. :-( Given that we've closed the CF entry for this thread and given that there seems to be enough context to these patches, I will move these patches back to their original thread, that is: * ModifyTable overheads in generic plans * https://www.postgresql.org/message-id/flat/CA%2BHiwqE4k1Q2TLmCAvekw%2B8_NXepbnfUOamOeX%3DKpHRDTfSKxA%40mail.gmail.com That will also make the CF-bot happy. -- Amit Langote EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: