On Mon, 28 Jun 2021 at 15:59, Amit Langote <amitlangot...@gmail.com> wrote: > > On Fri, Jun 25, 2021 at 10:26 AM David Rowley <dgrowle...@gmail.com> wrote: > > I wonder, since we can't delay taking locks until after run-time > > pruning due to being unable to invalidate cached plans, maybe instead > > we could tag on any PartitionPruneInfo onto the PlannedStmt itself and > > do the init plan run-time prune run during AcquireExecutorLocks(). > > This is exactly what I was mulling doing when working on [1] some last > year, after an off-list discussion with Robert (he suggested the idea > IIRC), though I never quite finished writing a patch. I have planned > to revisit this topic ("locking overhead in generic plans") for v15, > now that we have *some* proposals mentioned in [1] committed to v14, > so can look into this.
I thought about this only a little bit more from when I wrote the above. I think it would require adding yet another stage of when we do run-time pruning. It should be possible to do pruning when there's GeneratePruningStepsContext.has_exec_param == true. However, I'm not so sure that we could do GeneratePruningStepsContext.has_mutable_arg. Evaluating the value for those requires some level of actual execution. That's a pity as we'd still need to take a bunch of extra locks in a case like: SELECT * FROM time_parted WHERE ts >= NOW() - INTERVAL '1 hour'; I see the param values are fairly easily accessible a couple of levels up from AcquireExecutorLocks() in GetCachedPlan(). > Anyway, do you agree with starting a thread to discuss possible > approaches to attack this? Agreed about the separate thread. We can discuss it further there. David > [1] > https://www.postgresql.org/message-id/ca+hiwqg7zrubmmih3wpsbz4s0h2ehywrnxeducky5hr3fwz...@mail.gmail.com