On Tue, 19 Feb 2019 at 12:56, Andres Freund <and...@anarazel.de> wrote: > Isn't a large portion of benefits in this patch going to be mooted by > the locking improvements discussed in the other threads? I.e. there's > hopefully not going to be a ton of cases with low overhead where we > acquire a lot of locks and release them very soon after. Sure, for DDL > etc we will, but I can't see this mattering from a performance POV?
I think this patch was born from Amit's partition planner improvement patch. If not that one, which other threads did you have in mind? A problem exists where, if using a PREPAREd statement to plan a query to a partitioned table containing many partitions that a generic plan will never be favoured over a custom plan since the generic plan might not be able to prune partitions like the custom plan can. The actual problem is around that we do need to at some point generate a generic plan in order to know it's more costly and that requires locking possibly every partition. When plan_cache_mode = auto, this is done on the 6th execution of the statement. After Amit's partition planner changes [1], the custom plan will only lock partitions that are not pruned, so the 6th execution of the statement bloats the local lock table. [1] https://commitfest.postgresql.org/22/1778/ -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
