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. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
