Re: Delay locking partitions during INSERT and UPDATE

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On Tue, 19 Feb 2019 at 11:11, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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? And if it doesn't,
>> how much does it really matter?

> Quite a bit. Here's an INSERT benchmark from the first email in this
> thread. The test was done with 10k partitions.

Um, this doesn't really address my question, since you're comparing
HEAD to the patch. I was wondering about the delta if we assume
Amit's patch is in and then apply this on top (assuming it even
applies...)

>> You can't really postpone taking
>> a lock on a relation that the planner is going to do anything
>> nontrivial with.

> Not sure what you mean here. This is an executor change. What does
> the planner care about what the executor does?

Are we talking about the same patch? The one I'm looking at seems
to be mostly planner and plancache changes:

src/backend/catalog/dependency.c | 1 +
src/backend/commands/createas.c | 1 +
src/backend/executor/execUtils.c | 20 +++++++++++---------
src/backend/nodes/copyfuncs.c | 1 +
src/backend/nodes/equalfuncs.c | 1 +
src/backend/nodes/outfuncs.c | 1 +
src/backend/nodes/readfuncs.c | 1 +
src/backend/optimizer/plan/planner.c | 2 ++
src/backend/optimizer/util/inherit.c | 11 +++++++++++
src/backend/parser/parse_relation.c | 2 ++
src/backend/replication/logical/worker.c | 1 +
src/backend/rewrite/rewriteHandler.c | 1 +
src/backend/utils/adt/ri_triggers.c | 2 ++
src/backend/utils/adt/ruleutils.c | 3 +++
src/backend/utils/cache/plancache.c | 15 +++++++++++----
src/include/nodes/parsenodes.h | 2 ++

BTW, I'm doubtful that putting planner outputs into RangeTblEntry
is a particularly good idea.

regards, tom lane