On Tue, 19 Feb 2019 at 12:50, Tom Lane <t...@sss.pgh.pa.us> wrote: > > [ reposting some questions asked in the wrong thread ] > > What I'd like to understand about this patch is how it relates > to Amit L.'s work on making the planner faster for partitioned > UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/). > I think that that might render this moot? Amit's already > getting rid of unnecessary partition locking.
(I'm still not certain of this patch myself and it does need me to do some more analysis to check on what was mentioned recently upthread, but...) As for the overlap with Amit's patch, it is true he's reducing the locking down to just non-pruned partitions, so for this patch, that only leaves us able to skip locking partitions that are about to be run-time pruned. That happens to be quite useful when using generic plans as it's quite possible that the planner is unable to prune any partitions and the executor would otherwise have to lock all of them, but perhaps only end up scanning 1 of them. It's true that when plan_cache_mode = auto that a generic plan doing this is unlikely to ever be chosen since the planner does not cost in the possibility of run-time pruning, but there's also plan_cache_mode = force_generic_plan. > In any case, I'd counsel against putting planner outputs into > RangeTblEntry. Someday we ought to make parse trees read-only > to the planner, as plan trees are to the executor; defining them > to carry planner results kneecaps any such effort before it starts. > Not to mention the unpleasant consequences for the footprint > of this patch. I agree that one day it would be nice to move towards having the planner never touch the parse, but I didn't really see it as anything much beyond what rellockmode is today. If we one day have a solution for that, then likely the same solution will support fixing the delaylock flag too. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services