Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable)
От | Tom Lane |
---|---|
Тема | Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable) |
Дата | |
Msg-id | 2488063.1672932517@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable) (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable)
|
Список | pgsql-hackers |
Amit Langote <amitlangote09@gmail.com> writes: > On Thu, Jan 5, 2023 at 4:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Here's a draft patch that does it like that. This seems like a win >> for more reasons than just pruning, because I was able to integrate >> the calculation into runtime setup of the expressions, so that we >> aren't doing an extra stringToNode() on them. > Thanks for the patch. This looks pretty neat and I agree that this > seems like a net win overall. Thanks for looking. >> I've not looked into what it'd take to back-patch this. We can't >> add a field to ResultRelInfo in released branches (cf 4b3e37993), >> but we might be able to repurpose RangeTblEntry.extraUpdatedCols. > I think we can make that work. Would you like me to give that a try? I'm on it already. AFAICT, the above won't actually work because we don't have RTEs for all ResultRelInfos (per the "relinfo->ri_RangeTableIndex != 0" test in ExecGetExtraUpdatedCols). Probably we need something more like what 4b3e37993 did. regards, tom lane
В списке pgsql-hackers по дате отправления: