Robert Haas <robertmhaas@gmail.com> writes:
> In my opinion, the most important theoretical issue here is around
> reuse of plans that are no longer entirely valid, but the parts that
> are no longer valid are certain to be pruned. If, because we know that
> some parameter has some particular value, we skip locking a bunch of
> partitions, then when we're executing the plan, those partitions need
> not exist any more -- or they could have different indexes, be
> detached from the partitioning hierarchy and subsequently altered,
> whatever.
Check.
> That seems fine to me provided that all of our code (and any
> third-party code) is careful not to rely on the portion of the plan
> that we've pruned away, and doesn't assume that (for example) we can
> still fetch the name of an index whose OID appears in there someplace.
... like EXPLAIN, for example?
If "pruning" means physical removal from the plan tree, then it's
probably all right. However, it looks to me like that doesn't
actually happen, or at least doesn't happen till much later, so
there's room for worry about a disconnect between what plancache.c
has verified and what executor startup will try to touch. As you
say, in the absence of any bugs, that's not a problem ... but if
there are such bugs, tracking them down would be really hard.
What I am skeptical about is that this work actually accomplishes
anything under real-world conditions. That's because if pruning would
save enough to make skipping the lock-acquisition phase worth the
trouble, the plan cache is almost certainly going to decide it should
be using a custom plan not a generic plan. Now if we had a better
cost model (or, indeed, any model at all) for run-time pruning effects
then maybe that situation could be improved. I think we'd be better
served to worry about that end of it before we spend more time making
the executor even less predictable.
Also, while I've not spent much time at all reading this patch,
it seems rather desperately undercommented, and a lot of the
new names are unintelligible. In particular, I suspect that the
patch is significantly redesigning when/where run-time pruning
happens (unless it's just letting that be run twice); but I don't
see any documentation or name changes suggesting where that
responsibility is now.
regards, tom lane
