On Mon, 26 Nov 2018 at 17:37, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2018/11/24 1:25, Tom Lane wrote: > > I'm beginning to think that postponing target-index locking to > > ExecInitModifyTable was a damfool idea and we should undo it. > > +1 > > Also as already proposed, InitPlan should lock result relation indexes > even for DELETEs.
I'd rather see it fixed another way. The reason being, if we get [1], then that opens the door to run-time partition pruning for UPDATE/DELETE, which is currently blocked due to lack of knowledge about baserestrictinfos for the base partitioned relation because inheritance_planner() does not plan for the partitioned table, only its partitions. Doing the index opening work during InitPlan() means we do that for all partitions, even the ones that will later be run-time pruned. If we can doing it during init of a ModifyTable node, then we can likely do it after the run-time pruning takes place. Since Amit and I are both working towards making partitioning faster, I imagined he would also not want to do something that could slow it down significantly, if there was some alternative way to fix it, at least. 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/ -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
