On 2018/11/27 6:19, David Rowley wrote: > On Mon, 26 Nov 2018 at 18:57, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> On 2018/11/26 14:25, David Rowley wrote: >>> I'm making efforts to delay per-partition work even further in the >>> executor, for example locking of the per-partition result relations >>> until after run-time pruning would be a significant win for >>> partitioned tables with many partitions when generic plans are in use. >>> Moving things back to InitPlan() flies in the face of that work. >>> >>> [1] https://commitfest.postgresql.org/20/1778/ >> >> That's an interesting point. Although, considering the concerns that Tom >> raised about the same index relation being locked such that lock-strength >> upgrade occurs (his example containing two CTEs), we'll have to find a way >> to do the ModifyTable run-time pruning such that result relations and >> their indexes (possibly under multiple ModifyTable nodes) are locked with >> RowExclusiveLock before they're locked with AccessShareLock lock as scan >> relations. For example, we might be able to find a way to do the >> ModifyTable run-time pruning in InitPlan before initializing plan trees. > > I thought my idea of the processing the rangetable at the end of > planning to determine the strongest lock per relation would have > solved that.
Yeah, would be nice to make that work. Thanks, Amit
