Re: Delay locking partitions during query execution

[ reposting some questions asked in the wrong thread ]

What I'd like to understand about this patch is how it relates
to Amit L.'s work on making the planner faster for partitioned
UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/).
I think that that might render this moot?  Amit's already
getting rid of unnecessary partition locking.

In any case, I'd counsel against putting planner outputs into
RangeTblEntry.  Someday we ought to make parse trees read-only
to the planner, as plan trees are to the executor; defining them
to carry planner results kneecaps any such effort before it starts.
Not to mention the unpleasant consequences for the footprint
of this patch.

            regards, tom lane