David Rowley <david.row...@2ndquadrant.com> writes: > On 8 October 2018 at 12:18, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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. Hmm, I'm afraid that's not terribly safe, unless there are ALTER TABLE restrictions on partitions that I'm not aware of. For instance, a leaf partition might have an index it didn't inherit from the parent, and the query plan might be intending to use that index. If you don't take lock on the leaf, you might not know that the index has been dropped so that a new plan is needed. The idea I had in mind was to allow hard pruning of any leaf that's been excluded *at plan time* based on partition constraints seen in its parent rel(s). That should be safe enough as long as we take locks on all the non-leaf rels --- then we'd know about any change in the constraint situation. Rather than coping with renumbering the RTEs, it might be easiest to invent an "RTE_DUMMY" RTE type that a hard-pruned RTE could be changed to. regards, tom lane