1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* planmain.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* Routines to plan a single query
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2000-03-21 06:12:12 +01:00
|
|
|
* What's in a name, anyway? The top-level entry point of the planner/
|
|
|
|
* optimizer is over in planner.c, not here as you might think from the
|
|
|
|
* file name. But this is the main code for planning a basic join operation,
|
|
|
|
* shorn of features like subselects, inheritance, aggregates, grouping,
|
|
|
|
* and so on. (Those are the things planner.c deals with.)
|
|
|
|
*
|
2002-06-20 22:29:54 +02:00
|
|
|
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2002-11-06 01:00:45 +01:00
|
|
|
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/planmain.c,v 1.71 2002/11/06 00:00:44 tgl Exp $
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "optimizer/clauses.h"
|
2000-02-15 21:49:31 +01:00
|
|
|
#include "optimizer/pathnode.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "optimizer/paths.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "optimizer/planmain.h"
|
|
|
|
#include "optimizer/tlist.h"
|
2000-09-12 23:07:18 +02:00
|
|
|
#include "parser/parsetree.h"
|
2000-07-27 06:51:04 +02:00
|
|
|
#include "utils/memutils.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
2000-02-15 21:49:31 +01:00
|
|
|
/*--------------------
|
1999-02-14 00:22:53 +01:00
|
|
|
* query_planner
|
2002-11-06 01:00:45 +01:00
|
|
|
* Generate a path (that is, a simplified plan) for a basic query,
|
|
|
|
* which may involve joins but not any fancier features.
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
2002-11-06 01:00:45 +01:00
|
|
|
* Since query_planner does not handle the toplevel processing (grouping,
|
|
|
|
* sorting, etc) it cannot select the best path by itself. It selects
|
|
|
|
* two paths: the cheapest path that produces the required tuples, independent
|
|
|
|
* of any ordering considerations, and the cheapest path that produces the
|
|
|
|
* required tuples in the required ordering, if there is a path that
|
|
|
|
* can produce them without an explicit top-level sort step. The caller
|
|
|
|
* (grouping_planner) will make the final decision about which to use.
|
|
|
|
*
|
|
|
|
* Input parameters:
|
|
|
|
* root is the query to plan
|
2000-03-21 06:12:12 +01:00
|
|
|
* tlist is the target list the query should produce (NOT root->targetList!)
|
2000-02-15 21:49:31 +01:00
|
|
|
* tuple_fraction is the fraction of tuples we expect will be retrieved
|
|
|
|
*
|
2002-11-06 01:00:45 +01:00
|
|
|
* Output parameters:
|
|
|
|
* *cheapest_path receives the overall-cheapest path for the query
|
|
|
|
* *sorted_path receives the cheapest presorted path for the query,
|
|
|
|
* if any (it may be NULL, or the same as cheapest_path)
|
|
|
|
*
|
|
|
|
* Note: the Query node also includes a query_pathkeys field, which is both
|
|
|
|
* an input and an output of query_planner(). The input value signals
|
|
|
|
* query_planner that the indicated sort order is wanted in the final output
|
|
|
|
* plan. But this value has not yet been "canonicalized", since the needed
|
|
|
|
* info does not get computed until we scan the qual clauses. We canonicalize
|
|
|
|
* it as soon as that task is done. (The main reason query_pathkeys is a
|
|
|
|
* Query field and not a passed parameter is that the low-level routines in
|
|
|
|
* indxpath.c need to see it.)
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
2000-02-15 21:49:31 +01:00
|
|
|
* tuple_fraction is interpreted as follows:
|
2000-04-12 19:17:23 +02:00
|
|
|
* 0 (or less): expect all tuples to be retrieved (normal case)
|
2000-02-15 21:49:31 +01:00
|
|
|
* 0 < tuple_fraction < 1: expect the given fraction of tuples available
|
|
|
|
* from the plan to be retrieved
|
|
|
|
* 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
|
2000-11-12 01:37:02 +01:00
|
|
|
* tuple_fraction the same as 0, grouping_planner has a different
|
|
|
|
* interpretation.
|
2000-02-15 21:49:31 +01:00
|
|
|
*--------------------
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2002-11-06 01:00:45 +01:00
|
|
|
void
|
|
|
|
query_planner(Query *root, List *tlist, double tuple_fraction,
|
|
|
|
Path **cheapest_path, Path **sorted_path)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-09-29 20:21:41 +02:00
|
|
|
List *constant_quals;
|
2002-11-06 01:00:45 +01:00
|
|
|
RelOptInfo *final_rel;
|
1998-02-26 05:46:47 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2000-09-29 20:21:41 +02:00
|
|
|
* If the query has an empty join tree, then it's something easy like
|
2001-03-22 05:01:46 +01:00
|
|
|
* "SELECT 2+2;" or "INSERT ... VALUES()". Fall through quickly.
|
1999-10-07 06:23:24 +02:00
|
|
|
*/
|
2000-09-29 20:21:41 +02:00
|
|
|
if (root->jointree->fromlist == NIL)
|
1999-10-07 06:23:24 +02:00
|
|
|
{
|
2002-11-06 01:00:45 +01:00
|
|
|
*cheapest_path = (Path *) create_result_path(NULL, NULL,
|
|
|
|
(List *) root->jointree->quals);
|
|
|
|
*sorted_path = NULL;
|
|
|
|
return;
|
1999-10-07 06:23:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2000-09-29 20:21:41 +02:00
|
|
|
* Pull out any non-variable WHERE clauses so these can be put in a
|
1999-10-07 06:23:24 +02:00
|
|
|
* toplevel "Result" node, where they will gate execution of the whole
|
|
|
|
* plan (the Result will not invoke its descendant plan unless the
|
|
|
|
* quals are true). Note that any *really* non-variable quals will
|
1999-09-26 04:28:44 +02:00
|
|
|
* have been optimized away by eval_const_expressions(). What we're
|
1999-10-07 06:23:24 +02:00
|
|
|
* mostly interested in here is quals that depend only on outer-level
|
|
|
|
* vars, although if the qual reduces to "WHERE FALSE" this path will
|
2000-09-29 20:21:41 +02:00
|
|
|
* also be taken.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-09-29 20:21:41 +02:00
|
|
|
root->jointree->quals = (Node *)
|
|
|
|
pull_constant_clauses((List *) root->jointree->quals,
|
|
|
|
&constant_quals);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
2002-11-06 01:00:45 +01:00
|
|
|
* init planner lists to empty
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1998-08-10 04:26:40 +02:00
|
|
|
root->base_rel_list = NIL;
|
2001-05-20 22:28:20 +02:00
|
|
|
root->other_rel_list = NIL;
|
1998-08-10 04:26:40 +02:00
|
|
|
root->join_rel_list = NIL;
|
2000-02-15 21:49:31 +01:00
|
|
|
root->equi_key_list = NIL;
|
1998-08-10 04:26:40 +02:00
|
|
|
|
2000-07-24 05:11:01 +02:00
|
|
|
/*
|
2002-03-12 01:52:10 +01:00
|
|
|
* Construct RelOptInfo nodes for all base relations in query.
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
2002-03-12 01:52:10 +01:00
|
|
|
(void) add_base_rels_to_query(root, (Node *) root->jointree);
|
2000-09-12 23:07:18 +02:00
|
|
|
|
|
|
|
/*
|
2002-03-12 01:52:10 +01:00
|
|
|
* Examine the targetlist and qualifications, adding entries to
|
|
|
|
* baserel targetlists for all referenced Vars. Restrict and join
|
|
|
|
* clauses are added to appropriate lists belonging to the mentioned
|
|
|
|
* relations. We also build lists of equijoined keys for pathkey
|
|
|
|
* construction.
|
2002-11-06 01:00:45 +01:00
|
|
|
*
|
|
|
|
* Note: all subplan nodes will have "flat" (var-only) tlists.
|
|
|
|
* This implies that all expression evaluations are done at the root of
|
|
|
|
* the plan tree. Once upon a time there was code to try to push
|
|
|
|
* expensive function calls down to lower plan nodes, but that's dead
|
|
|
|
* code and has been for a long time...
|
2000-07-24 05:11:01 +02:00
|
|
|
*/
|
2002-11-06 01:00:45 +01:00
|
|
|
build_base_rel_tlists(root, tlist);
|
2000-09-12 23:07:18 +02:00
|
|
|
|
2002-03-12 01:52:10 +01:00
|
|
|
(void) distribute_quals_to_rels(root, (Node *) root->jointree);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-24 05:11:01 +02:00
|
|
|
/*
|
|
|
|
* Use the completed lists of equijoined keys to deduce any implied
|
|
|
|
* but unstated equalities (for example, A=B and B=C imply A=C).
|
|
|
|
*/
|
|
|
|
generate_implied_equalities(root);
|
|
|
|
|
2000-02-15 21:49:31 +01:00
|
|
|
/*
|
2000-04-12 19:17:23 +02:00
|
|
|
* We should now have all the pathkey equivalence sets built, so it's
|
|
|
|
* now possible to convert the requested query_pathkeys to canonical
|
|
|
|
* form.
|
2000-02-15 21:49:31 +01:00
|
|
|
*/
|
|
|
|
root->query_pathkeys = canonicalize_pathkeys(root, root->query_pathkeys);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ready to do the primary planning.
|
|
|
|
*/
|
2000-02-07 05:41:04 +01:00
|
|
|
final_rel = make_one_rel(root);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-11-06 01:00:45 +01:00
|
|
|
if (!final_rel || !final_rel->cheapest_total_path)
|
|
|
|
elog(ERROR, "query_planner: failed to construct a relation");
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-08-21 05:49:17 +02:00
|
|
|
/*
|
2000-04-12 19:17:23 +02:00
|
|
|
* Now that we have an estimate of the final rel's size, we can
|
|
|
|
* convert a tuple_fraction specified as an absolute count (ie, a
|
|
|
|
* LIMIT option) into a fraction of the total tuples.
|
2000-02-15 21:49:31 +01:00
|
|
|
*/
|
|
|
|
if (tuple_fraction >= 1.0)
|
|
|
|
tuple_fraction /= final_rel->rows;
|
|
|
|
|
|
|
|
/*
|
2002-11-06 01:00:45 +01:00
|
|
|
* Pick out the cheapest-total path and the cheapest presorted path
|
|
|
|
* for the requested pathkeys (if there is one). We can take the
|
|
|
|
* tuple fraction into account when selecting the cheapest presorted
|
|
|
|
* path, but not when selecting the cheapest-total path, since if we
|
|
|
|
* have to sort then we'll have to fetch all the tuples. (But there's
|
|
|
|
* a special case: if query_pathkeys is NIL, meaning order doesn't
|
|
|
|
* matter, then the "cheapest presorted" path will be the cheapest
|
|
|
|
* overall for the tuple fraction.)
|
2000-02-15 21:49:31 +01:00
|
|
|
*/
|
2002-11-06 01:00:45 +01:00
|
|
|
*cheapest_path = final_rel->cheapest_total_path;
|
2000-02-15 21:49:31 +01:00
|
|
|
|
2002-11-06 01:00:45 +01:00
|
|
|
*sorted_path =
|
2000-02-15 21:49:31 +01:00
|
|
|
get_cheapest_fractional_path_for_pathkeys(final_rel->pathlist,
|
|
|
|
root->query_pathkeys,
|
|
|
|
tuple_fraction);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-10-07 06:23:24 +02:00
|
|
|
/*
|
2002-11-06 01:00:45 +01:00
|
|
|
* If we have constant quals, add a toplevel Result step to process them.
|
1999-08-21 05:49:17 +02:00
|
|
|
*/
|
2002-11-06 01:00:45 +01:00
|
|
|
if (constant_quals)
|
|
|
|
{
|
|
|
|
*cheapest_path = (Path *)
|
|
|
|
create_result_path((*cheapest_path)->parent,
|
|
|
|
*cheapest_path,
|
|
|
|
constant_quals);
|
|
|
|
if (*sorted_path)
|
|
|
|
*sorted_path = (Path *)
|
|
|
|
create_result_path((*sorted_path)->parent,
|
|
|
|
*sorted_path,
|
|
|
|
constant_quals);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|