|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)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
|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|