Re: Runtime pruning problem

On 2019/04/17 13:10, Tom Lane wrote:
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
>> On Wed, 17 Apr 2019 at 15:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> What I'm more worried about is whether this breaks any internal behavior
>>> of explain.c, as the comment David quoted upthread seems to think.
>>> If we need to have a tlist to reference, can we make that code look
>>> to the pre-pruning plan tree, rather than the planstate tree?
>
>> I think most of the complexity is in what to do in
>> set_deparse_planstate() given that there might be no outer plan to
>> choose from for Append and MergeAppend. This controls what's done in
>> resolve_special_varno() as this descends the plan tree down the outer
>> side until it gets to the node that the outer var came from.
>
>> We wouldn't need to do this if we just didn't show the targetlist in
>> EXPLAIN VERBOSE, but there's also MergeAppend sort keys to worry about
>> too. Should we just skip on those as well?
>
> No, the larger issue is that *any* plan node above the Append might
> be recursing down to/through the Append to find out what to print for
> a Var reference. We have to be able to support that.

Hmm, yes.

I see that the targetlist of Append, MergeAppend, and ModifyTable nodes is
finalized using set_dummy_tlist_references(), wherein the Vars in the
nodes' (Plan struct's) targetlist are modified to be OUTER_VAR vars. The
comments around set_dummy_tlist_references() says it's done for explain.c
to intercept any accesses to variables in these nodes' targetlist and
return the corresponding variables in the nodes' 1st child subplan's
targetlist, which must have all the variables in the nodes' targetlist.c.
This arrangement makes it mandatory for these nodes to have at least one
subplan, so the hack in runtime pruning code.

I wonder why the original targetlist of these nodes, adjusted using just
fix_scan_list(), wouldn't have been better for EXPLAIN to use? If I
replace the set_dummy_tlist_references() call by fix_scan_list() for
Append for starters, I see that the targetlist of any nodes on top of the
Append list the Append's output variables without a "refname" prefix.
That can be confusing if the same parent table (Append's parent relation)
is referenced multiple times. The refname is empty, because
select_rtable_names_for_explain() thinks an Append hasn't got one. Same
is true for MergeAppend. ModifyTable, OTOH, has one because it has the
nominalRelation field. Maybe it's not possible to have such a field for
Append and MergeAppend, because they don't *always* refer to a single
table (UNION ALL, partitionwise join come to mind). Anyway, even if we do
manage to print a refname for Append/MergeAppend somehow, that wouldn't be
back-patchable to 11.

Another idea is to teach explain.c about this special case of run-time
pruning having pruned all child subplans even though appendplans contains
one element to cater for targetlist accesses. That is, Append will be
displayed with "Subplans Removed: All" and no child subplans listed below
it, even though appendplans[] has one. David already said he didn't do in
the first place to avoid PartitionPruneInfo details creeping into other
modules, but maybe there's no other way?

Thanks,
Amit