database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-04 20:11:56 +03:00
Code Activity

Simplify query_planner's API by having it return the top-level RelOptInfo.

Browse Source 
Formerly, query_planner returned one or possibly two Paths for the topmost
join relation, so that grouping_planner didn't see the join RelOptInfo
(at least not directly; it didn't have any hesitation about examining
cheapest_path->parent, though).  However, correct selection of the Paths
involved a significant amount of coupling between query_planner and
grouping_planner, a problem which has gotten worse over time.  It seems
best to give up on this API choice and instead return the topmost
RelOptInfo explicitly.  Then grouping_planner can pull out the Paths it
wants from the rel's path list.  In this way we can remove all knowledge
of grouping behaviors from query_planner.

The only real benefit of the old way is that in the case of an empty
FROM clause, we never made any RelOptInfos at all, just a Path.  Now
we have to gin up a dummy RelOptInfo to represent the empty FROM clause.
That's not a very big deal though.

While at it, simplify query_planner's API a bit more by having the caller
set up root->tuple_fraction and root->limit_tuples, rather than passing
those values as separate parameters.  Since query_planner no longer does
anything with either value, requiring it to fill the PlannerInfo fields
seemed pretty arbitrary.

This patch just rearranges code; it doesn't (intentionally) change any
behaviors.  Followup patches will do more interesting things.
This commit is contained in:
Tom Lane
2013-08-05 15:00:57 -04:00
parent 841c29c8b3
commit 3ced8837db
8 changed files with 247 additions and 277 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
src/backend/optimizer/prep/prepjointree.c
View File

@@ -1333,15 +1333,16 @@ is_simple_subquery(Query *subquery, RangeTblEntry *rte,
return false;
/*
* Hack: don't try to pull up a subquery with an empty jointree.
* query_planner() will correctly generate a Result plan for a jointree
* that's totally empty, but I don't think the right things happen if an
* empty FromExpr appears lower down in a jointree. It would pose a
* problem for the PlaceHolderVar mechanism too, since we'd have no way to
* identify where to evaluate a PHV coming out of the subquery. Not worth
* working hard on this, just to collapse SubqueryScan/Result into Result;
* especially since the SubqueryScan can often be optimized away by
* setrefs.c anyway.
* Don't pull up a subquery with an empty jointree. query_planner() will
* correctly generate a Result plan for a jointree that's totally empty,
* but we can't cope with an empty FromExpr appearing lower down in a
* jointree: we identify join rels via baserelid sets, so we couldn't
* distinguish a join containing such a FromExpr from one without it.
* This would for example break the PlaceHolderVar mechanism, since we'd
* have no way to identify where to evaluate a PHV coming out of the
* subquery. Not worth working hard on this, just to collapse
* SubqueryScan/Result into Result; especially since the SubqueryScan can
* often be optimized away by setrefs.c anyway.
*/
if (subquery->jointree->fromlist == NIL)
return false;