Re: Runtime pruning problem
От | Amit Langote |
---|---|
Тема | Re: Runtime pruning problem |
Дата | |
Msg-id | f1ad1911-df47-b555-8df5-825e3a8aa69c@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Runtime pruning problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Runtime pruning problem
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
On 2019/04/17 13:10, Tom Lane wrote: > David Rowley <david.rowley@2ndquadrant.com> writes: >> On Wed, 17 Apr 2019 at 15:54, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Amit LangoteДата:
Сообщение: Re: bug in update tuple routing with foreign partitions