On Thu, 24 Jun 2021 at 12:14, Tom Lane <t...@sss.pgh.pa.us> wrote: > > David Rowley <dgrowle...@gmail.com> writes: > > But... maybe there are some cases where a user can be certain that all > > interesting records are contained in a single partition but > > partitioning pruning cannot prove it...So maybe what you say is right. > > The workaround there would be to add a qual that allows pruning to > > work. > > [ shrug... ] It's about as easy to just name the partition you want. > When planning overhead is considered, maybe it's a lot easier.
I'm not suggesting that we go and make it impossible for users to directly reference partitions today. What I mean is that as we add more and more fixes to improve performance of partitioning, that there comes a point where the ability to directly reference partitions is a hindrance rather than something that's useful. Right now that hindrance is the fact that we must lock every single partition in the plan. We only need to do that in case some other backend is doing something that bypasses taking a lock on the parent partitioned table. 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. David
