On 8 October 2018 at 12:18, Tom Lane <t...@sss.pgh.pa.us> wrote: > However, we should keep in mind that without partitioning overhead > (ie "select * from lt_999 where b = 999 for share"), the TPS rate > is over 25800 tps. Most of the overhead in the partitioned case seems > to be from acquiring locks on rangetable entries that we won't ever > use, and none of these patch variants are touching that problem. > So ISTM that the *real* win for this scenario is going to come from > teaching the system to prune unwanted relations from the query > altogether, not just from the PlanRowMark list.
Idle thought: I wonder if we could add another field to the RangeTblEntry; "delaylock". Set that to true in the planner for all other_member rels that are partitions then not obtain locks on those during AcquireExecutorLocks(). Instead, grab the lock in ExecGetRangeTableRelation() the first time through. We'd still obtain the lock for the table named in the query at the normal time so cached plans could properly be invalidated. We'd need to ensure that anything that could be changed in the partitions to cause a plan to become invalid properly obtains a lock on the partitioned table, all the way to the top of the hierarchy. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services