Add an alternative_plan_name field to PlannerInfo. Typically, we have only one PlannerInfo for any given subquery, but when we are considering a MinMaxAggPath or a hashed subplan, we end up creating a second PlannerInfo for the same portion of the query, with a clone of the original range table. In fact, in the MinMaxAggPath case, we might end up creating several clones, one per aggregate.
At present, there's no easy way for a plugin, such as pg_plan_advice, to understand the relationships between the original range table and the copies of it that are created in these cases. To fix, add an alternative_plan_name field to PlannerInfo. For a hashed subplan, this is the plan name for the non-hashed alternative; for minmax aggregates, this is the plan_name from the parent PlannerInfo; otherwise, it's the same as plan_name. Discussion: http://postgr.es/m/ca+tgmoyuwmn-00ec5py7zacpsfquqlbgadvwgr9kor-hm-f...@mail.gmail.com Reviewed-by: Lukas Fittl <[email protected]> Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/26255a320733de2d91a30bd6ae529dd01e7f3409 Modified Files -------------- src/backend/optimizer/path/allpaths.c | 2 +- src/backend/optimizer/plan/planagg.c | 1 + src/backend/optimizer/plan/planner.c | 15 +++++++++++---- src/backend/optimizer/plan/subselect.c | 6 +++--- src/backend/optimizer/prep/prepjointree.c | 1 + src/backend/optimizer/prep/prepunion.c | 2 +- src/include/nodes/pathnodes.h | 12 ++++++++++++ src/include/optimizer/planner.h | 1 + 8 files changed, 31 insertions(+), 9 deletions(-)
