On Thu, 24 Jun 2021 at 12:32, David Rowley <dgrowle...@gmail.com> wrote: > The overhead of taking these locks is pretty significant for > partitioned tables with lots of partitions where only 1 of them > survives run-time partition pruning. That's really terrible for > people that want to PREPARE queries and just look up a single row from > a single partition. That seems like a pretty big use case that we're > just terrible at today.
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(). A lock would need to be taken on each partitioned table before we prune for it. So if there was multi-level partitioning, we'd need to lock the partitioned table, do pruning for that partitioned table, then lock any sub-partitioned tables before doing pruning on those. I don't immediately see why it couldn't be made to work, it's just that it adds quite a lot of complexity to what's being done in AcquireExecutorLocks(), which today is a very simple function. David
