On Tue, 19 Feb 2019 at 12:50, Tom Lane <tgl@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