From 6543d81d659f4176c6530fb09eef83deede264a0 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 12 Nov 2000 00:37:02 +0000 Subject: Restructure handling of inheritance queries so that they work with outer joins, and clean things up a good deal at the same time. Append plan node no longer hacks on rangetable at runtime --- instead, all child tables are given their own RT entries during planning. Concept of multiple target tables pushed up into execMain, replacing bug-prone implementation within nodeAppend. Planner now supports generating Append plans for inheritance sets either at the top of the plan (the old way) or at the bottom. Expanding at the bottom is appropriate for tables used as sources, since they may appear inside an outer join; but we must still expand at the top when the target of an UPDATE or DELETE is an inheritance set, because we actually need a different targetlist and junkfilter for each target table in that case. Fortunately a target table can't be inside an outer join... Bizarre mutual recursion between union_planner and prepunion.c is gone --- in fact, union_planner doesn't really have much to do with union queries anymore, so I renamed it grouping_planner. --- src/backend/optimizer/plan/planmain.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) (limited to 'src/backend/optimizer/plan/planmain.c') diff --git a/src/backend/optimizer/plan/planmain.c b/src/backend/optimizer/plan/planmain.c index a9747b32799..1a923a506ff 100644 --- a/src/backend/optimizer/plan/planmain.c +++ b/src/backend/optimizer/plan/planmain.c @@ -14,7 +14,7 @@ * * * IDENTIFICATION - * $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planmain.c,v 1.61 2000/10/05 19:11:29 tgl Exp $ + * $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planmain.c,v 1.62 2000/11/12 00:36:58 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -65,7 +65,8 @@ static Plan *subplanner(Query *root, List *flat_tlist, * tuple_fraction >= 1: tuple_fraction is the absolute number of tuples * expected to be retrieved (ie, a LIMIT specification) * Note that while this routine and its subroutines treat a negative - * tuple_fraction the same as 0, union_planner has a different interpretation. + * tuple_fraction the same as 0, grouping_planner has a different + * interpretation. * * Returns a query plan. *-------------------- @@ -125,9 +126,16 @@ query_planner(Query *root, subplan = subplanner(root, var_only_tlist, tuple_fraction); /* - * Build a result node to control the plan if we have constant quals. + * Build a result node to control the plan if we have constant quals, + * or if the top-level plan node is one that cannot do expression + * evaluation (it won't be able to evaluate the requested tlist). + * Currently, the only plan node we might see here that falls into + * that category is Append. + * + * XXX future improvement: if the given tlist is flat anyway, we don't + * really need a Result node. */ - if (constant_quals) + if (constant_quals || IsA(subplan, Append)) { /* @@ -325,8 +333,8 @@ subplanner(Query *root, /* * Nothing for it but to sort the cheapest-total-cost path --- but we - * let the caller do that. union_planner has to be able to add a sort - * node anyway, so no need for extra code here. (Furthermore, the + * let the caller do that. grouping_planner has to be able to add a + * sort node anyway, so no need for extra code here. (Furthermore, the * given pathkeys might involve something we can't compute here, such * as an aggregate function...) */ -- cgit v1.2.3