Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable)

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: 2023-01-05T15:28:37Z
Lists: 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



Commits

  1. Fix calculation of which GENERATED columns need to be updated.

  2. Push lpp variable closer to usage in heapgetpage()