On 2018/10/08 9:29, David Rowley wrote: > On 8 October 2018 at 13:13, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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. > > The problem with that is that, if we get [1] done in PG12, then the > RTE_DUMMYs would not exist, as we'd only have RTEs in the range table > for partitions that survived plan-time pruning. ...
> [1] https://commitfest.postgresql.org/20/1778/ Yeah, the patch proposed at [1] postpones creating partition RTEs (hence locking them) to a point after pruning, which also means we create only the necessary RTEs. In fact, it's not just the RTEs, but child PlanRowMarks, whose creation is postponed to after pruning. So, I admitted upthread that my proposed patch here would only add code that will become useless if we're able to get [1] in. Thanks, Amit
