Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable)
Date: 2023-01-04 19:59:11
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> After further thought: maybe we should get radical and postpone this
> work all the way to executor startup. The downside of that is having
> to do it over again on each execution of a prepared plan. But the
> upside is that when the UPDATE targets a many-partitioned table,
> we would have a chance at not doing the work at all for partitions
> that get pruned at runtime. I'm not sure if that win would emerge
> immediately or if we still have executor work to do to manage pruning
> of the target table. I'm also not sure that this'd be a net win
> overall. But it seems worth considering.

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.

There's still a code path that does such a calculation at plan time
(get_rel_all_updated_cols), but it's only used by postgres_fdw which
has some other rather-inefficient behaviors in the same area.

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.

regards, tom lane

Attachment Content-Type Size
compute-extraUpdatedCols-at-runtime-1.patch text/x-diff 22.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-01-04 20:56:34 Re: allowing for control over SET ROLE
Previous Message David Rowley 2023-01-04 19:40:59 Re: grouping pushdown