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.)
|
|
|
|
*
|
2007-01-05 23:20:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2007, 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
|
2007-04-21 23:01:45 +02:00
|
|
|
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planmain.c,v 1.100 2007/04/21 21:01:45 tgl Exp $
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2002-11-21 01:42:20 +01:00
|
|
|
#include "optimizer/cost.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"
|
2005-08-28 00:13:44 +02:00
|
|
|
#include "optimizer/tlist.h"
|
|
|
|
#include "utils/selfuncs.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
2005-08-28 00:13:44 +02: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,
|
2003-08-04 02:43:34 +02:00
|
|
|
* sorting, etc) it cannot select the best path by itself. It selects
|
2002-11-21 01:42:20 +01:00
|
|
|
* two paths: the cheapest path that produces all the required tuples,
|
|
|
|
* independent of any ordering considerations, and the cheapest path that
|
|
|
|
* produces the expected fraction of the required tuples in the required
|
|
|
|
* ordering, if there is a path that is cheaper for this than just sorting
|
|
|
|
* the output of the cheapest overall path. The caller (grouping_planner)
|
|
|
|
* will make the final decision about which to use.
|
2002-11-06 01:00:45 +01:00
|
|
|
*
|
|
|
|
* Input parameters:
|
2005-06-06 00:32:58 +02:00
|
|
|
* root describes the query to plan
|
|
|
|
* tlist is the target list the query should produce
|
|
|
|
* (this is NOT necessarily root->parse->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,
|
2002-11-21 01:42:20 +01:00
|
|
|
* if any (NULL if there is no useful presorted path)
|
2005-08-28 00:13:44 +02:00
|
|
|
* *num_groups receives the estimated number of groups, or 1 if query
|
|
|
|
* does not use grouping
|
2002-11-06 01:00:45 +01:00
|
|
|
*
|
2005-06-06 00:32:58 +02:00
|
|
|
* Note: the PlannerInfo node also includes a query_pathkeys field, which is
|
2005-10-15 04:49:52 +02:00
|
|
|
* both an input and an output of query_planner(). The input value signals
|
2002-11-06 01:00:45 +01:00
|
|
|
* 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
|
2005-06-06 00:32:58 +02:00
|
|
|
* PlannerInfo 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
|
|
|
*
|
2005-08-28 00:13:44 +02:00
|
|
|
* Note: the PlannerInfo node also includes group_pathkeys and sort_pathkeys,
|
|
|
|
* which like query_pathkeys need to be canonicalized once the info is
|
|
|
|
* available.
|
|
|
|
*
|
2000-02-15 21:49:31 +01:00
|
|
|
* tuple_fraction is interpreted as follows:
|
2003-03-10 04:53:52 +01:00
|
|
|
* 0: 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)
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2002-11-06 01:00:45 +01:00
|
|
|
void
|
2005-06-06 00:32:58 +02:00
|
|
|
query_planner(PlannerInfo *root, List *tlist, double tuple_fraction,
|
2005-08-28 00:13:44 +02:00
|
|
|
Path **cheapest_path, Path **sorted_path,
|
|
|
|
double *num_groups)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2005-06-06 00:32:58 +02:00
|
|
|
Query *parse = root->parse;
|
2005-12-20 03:30:36 +01:00
|
|
|
List *joinlist;
|
2002-11-06 01:00:45 +01:00
|
|
|
RelOptInfo *final_rel;
|
2002-11-21 01:42:20 +01:00
|
|
|
Path *cheapestpath;
|
|
|
|
Path *sortedpath;
|
2006-09-20 00:49:53 +02:00
|
|
|
Index rti;
|
2007-04-21 23:01:45 +02:00
|
|
|
ListCell *lc;
|
2006-09-20 00:49:53 +02:00
|
|
|
double total_pages;
|
1998-02-26 05:46:47 +01:00
|
|
|
|
2005-06-10 05:32:25 +02:00
|
|
|
/* Make tuple_fraction accessible to lower-level routines */
|
|
|
|
root->tuple_fraction = tuple_fraction;
|
|
|
|
|
2005-08-28 00:13:44 +02:00
|
|
|
*num_groups = 1; /* default result */
|
|
|
|
|
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
|
|
|
*/
|
2005-06-06 00:32:58 +02:00
|
|
|
if (parse->jointree->fromlist == NIL)
|
1999-10-07 06:23:24 +02:00
|
|
|
{
|
Revise the planner's handling of "pseudoconstant" WHERE clauses, that is
clauses containing no variables and no volatile functions. Such a clause
can be used as a one-time qual in a gating Result plan node, to suppress
plan execution entirely when it is false. Even when the clause is true,
putting it in a gating node wins by avoiding repeated evaluation of the
clause. In previous PG releases, query_planner() would do this for
pseudoconstant clauses appearing at the top level of the jointree, but
there was no ability to generate a gating Result deeper in the plan tree.
To fix it, get rid of the special case in query_planner(), and instead
process pseudoconstant clauses through the normal RestrictInfo qual
distribution mechanism. When a pseudoconstant clause is found attached to
a path node in create_plan(), pull it out and generate a gating Result at
that point. This requires special-casing pseudoconstants in selectivity
estimation and cost_qual_eval, but on the whole it's pretty clean.
It probably even makes the planner a bit faster than before for the normal
case of no pseudoconstants, since removing pull_constant_clauses saves one
useless traversal of the qual tree. Per gripe from Phil Frost.
2006-07-01 20:38:33 +02:00
|
|
|
*cheapest_path = (Path *)
|
|
|
|
create_result_path((List *) parse->jointree->quals);
|
2002-11-06 01:00:45 +01:00
|
|
|
*sorted_path = NULL;
|
|
|
|
return;
|
1999-10-07 06:23:24 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2006-01-31 22:39:25 +01:00
|
|
|
* Init planner lists to empty, and set up the array to hold RelOptInfos
|
|
|
|
* for "simple" rels.
|
2003-01-20 19:55:07 +01:00
|
|
|
*
|
2006-01-31 22:39:25 +01:00
|
|
|
* NOTE: in_info_list and append_rel_list were set up by subquery_planner,
|
2007-01-20 21:45:41 +01:00
|
|
|
* do not touch here; eq_classes may contain data already, too.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2006-01-31 22:39:25 +01:00
|
|
|
root->simple_rel_array_size = list_length(parse->rtable) + 1;
|
|
|
|
root->simple_rel_array = (RelOptInfo **)
|
|
|
|
palloc0(root->simple_rel_array_size * sizeof(RelOptInfo *));
|
1998-08-10 04:26:40 +02:00
|
|
|
root->join_rel_list = NIL;
|
2005-06-09 01:02:05 +02:00
|
|
|
root->join_rel_hash = NULL;
|
2007-01-20 21:45:41 +01:00
|
|
|
root->canon_pathkeys = NIL;
|
Teach planner about some cases where a restriction clause can be
propagated inside an outer join. In particular, given
LEFT JOIN ON (A = B) WHERE A = constant, we cannot conclude that
B = constant at the top level (B might be null instead), but we
can nonetheless put a restriction B = constant into the quals for
B's relation, since no inner-side rows not meeting that condition
can contribute to the final result. Similarly, given
FULL JOIN USING (J) WHERE J = constant, we can't directly conclude
that either input J variable = constant, but it's OK to push such
quals into each input rel. Per recent gripe from Kim Bisgaard.
Along the way, remove 'valid_everywhere' flag from RestrictInfo,
as on closer analysis it was not being used for anything, and was
defined backwards anyway.
2005-07-03 01:00:42 +02:00
|
|
|
root->left_join_clauses = NIL;
|
|
|
|
root->right_join_clauses = NIL;
|
|
|
|
root->full_join_clauses = NIL;
|
2005-12-20 03:30:36 +01:00
|
|
|
root->oj_info_list = NIL;
|
1998-08-10 04:26:40 +02:00
|
|
|
|
2007-04-21 23:01:45 +02:00
|
|
|
/*
|
|
|
|
* Make a flattened version of the rangetable for faster access (this
|
|
|
|
* is OK because the rangetable won't change any more).
|
|
|
|
*/
|
|
|
|
root->simple_rte_array = (RangeTblEntry **)
|
|
|
|
palloc0(root->simple_rel_array_size * sizeof(RangeTblEntry *));
|
|
|
|
rti = 1;
|
|
|
|
foreach(lc, parse->rtable)
|
|
|
|
{
|
|
|
|
RangeTblEntry *rte = (RangeTblEntry *) lfirst(lc);
|
|
|
|
|
|
|
|
root->simple_rte_array[rti++] = rte;
|
|
|
|
}
|
|
|
|
|
2000-07-24 05:11:01 +02:00
|
|
|
/*
|
2006-09-20 00:49:53 +02:00
|
|
|
* Construct RelOptInfo nodes for all base relations in query, and
|
|
|
|
* indirectly for all appendrel member relations ("other rels"). This
|
2006-10-04 02:30:14 +02:00
|
|
|
* will give us a RelOptInfo for every "simple" (non-join) rel involved in
|
|
|
|
* the query.
|
2006-09-20 00:49:53 +02:00
|
|
|
*
|
|
|
|
* Note: the reason we find the rels by searching the jointree and
|
|
|
|
* appendrel list, rather than just scanning the rangetable, is that the
|
|
|
|
* rangetable may contain RTEs for rels not actively part of the query,
|
|
|
|
* for example views. We don't want to make RelOptInfos for them.
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
2005-06-06 00:32:58 +02:00
|
|
|
add_base_rels_to_query(root, (Node *) parse->jointree);
|
2000-09-12 23:07:18 +02:00
|
|
|
|
2006-09-20 00:49:53 +02:00
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* We should now have size estimates for every actual table involved in
|
|
|
|
* the query, so we can compute total_table_pages. Note that appendrels
|
|
|
|
* are not double-counted here, even though we don't bother to distinguish
|
|
|
|
* RelOptInfos for appendrel parents, because the parents will still have
|
|
|
|
* size zero.
|
2006-09-20 00:49:53 +02:00
|
|
|
*
|
|
|
|
* XXX if a table is self-joined, we will count it once per appearance,
|
|
|
|
* which perhaps is the wrong thing ... but that's not completely clear,
|
|
|
|
* and detecting self-joins here is difficult, so ignore it for now.
|
|
|
|
*/
|
|
|
|
total_pages = 0;
|
|
|
|
for (rti = 1; rti < root->simple_rel_array_size; rti++)
|
|
|
|
{
|
|
|
|
RelOptInfo *brel = root->simple_rel_array[rti];
|
|
|
|
|
|
|
|
if (brel == NULL)
|
|
|
|
continue;
|
|
|
|
|
2006-10-04 02:30:14 +02:00
|
|
|
Assert(brel->relid == rti); /* sanity check on array */
|
2006-09-20 00:49:53 +02:00
|
|
|
|
|
|
|
total_pages += (double) brel->pages;
|
|
|
|
}
|
|
|
|
root->total_table_pages = total_pages;
|
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02: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
|
2007-01-20 21:45:41 +01:00
|
|
|
* also build EquivalenceClasses for provably equivalent expressions,
|
|
|
|
* and form a target joinlist for make_one_rel() to work from.
|
2002-11-06 01:00:45 +01:00
|
|
|
*
|
2005-11-22 19:17:34 +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
|
|
|
|
2005-12-20 03:30:36 +01:00
|
|
|
joinlist = deconstruct_jointree(root);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-24 05:11:01 +02:00
|
|
|
/*
|
2007-01-20 21:45:41 +01:00
|
|
|
* Reconsider any postponed outer-join quals now that we have built up
|
|
|
|
* equivalence classes. (This could result in further additions or
|
|
|
|
* mergings of classes.)
|
2000-07-24 05:11:01 +02:00
|
|
|
*/
|
2007-01-20 21:45:41 +01:00
|
|
|
reconsider_outer_join_clauses(root);
|
2000-07-24 05:11:01 +02:00
|
|
|
|
2000-02-15 21:49:31 +01:00
|
|
|
/*
|
2007-01-20 21:45:41 +01:00
|
|
|
* If we formed any equivalence classes, generate additional restriction
|
|
|
|
* clauses as appropriate. (Implied join clauses are formed on-the-fly
|
|
|
|
* later.)
|
|
|
|
*/
|
|
|
|
generate_base_implied_equalities(root);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We have completed merging equivalence sets, so it's now possible to
|
|
|
|
* convert the requested query_pathkeys to canonical form. Also
|
|
|
|
* canonicalize the groupClause and sortClause pathkeys for use later.
|
2000-02-15 21:49:31 +01:00
|
|
|
*/
|
|
|
|
root->query_pathkeys = canonicalize_pathkeys(root, root->query_pathkeys);
|
2005-08-28 00:13:44 +02:00
|
|
|
root->group_pathkeys = canonicalize_pathkeys(root, root->group_pathkeys);
|
|
|
|
root->sort_pathkeys = canonicalize_pathkeys(root, root->sort_pathkeys);
|
2000-02-15 21:49:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Ready to do the primary planning.
|
|
|
|
*/
|
2005-12-20 03:30:36 +01:00
|
|
|
final_rel = make_one_rel(root, joinlist);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-11-06 01:00:45 +01:00
|
|
|
if (!final_rel || !final_rel->cheapest_total_path)
|
2003-07-25 02:01:09 +02:00
|
|
|
elog(ERROR, "failed to construct the join relation");
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-08-21 05:49:17 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* If there's grouping going on, estimate the number of result groups. We
|
|
|
|
* couldn't do this any earlier because it depends on relation size
|
2005-08-28 00:13:44 +02:00
|
|
|
* estimates that were set up above.
|
|
|
|
*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Then convert tuple_fraction to fractional form if it is absolute, and
|
|
|
|
* adjust it based on the knowledge that grouping_planner will be doing
|
|
|
|
* grouping or aggregation work with our result.
|
2005-08-28 00:13:44 +02:00
|
|
|
*
|
|
|
|
* This introduces some undesirable coupling between this code and
|
|
|
|
* grouping_planner, but the alternatives seem even uglier; we couldn't
|
|
|
|
* pass back completed paths without making these decisions here.
|
2000-02-15 21:49:31 +01:00
|
|
|
*/
|
2005-08-28 00:13:44 +02:00
|
|
|
if (parse->groupClause)
|
|
|
|
{
|
|
|
|
List *groupExprs;
|
|
|
|
|
|
|
|
groupExprs = get_sortgrouplist_exprs(parse->groupClause,
|
|
|
|
parse->targetList);
|
|
|
|
*num_groups = estimate_num_groups(root,
|
|
|
|
groupExprs,
|
|
|
|
final_rel->rows);
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* In GROUP BY mode, an absolute LIMIT is relative to the number of
|
|
|
|
* groups not the number of tuples. If the caller gave us a fraction,
|
|
|
|
* keep it as-is. (In both cases, we are effectively assuming that
|
|
|
|
* all the groups are about the same size.)
|
2005-08-28 00:13:44 +02:00
|
|
|
*/
|
|
|
|
if (tuple_fraction >= 1.0)
|
|
|
|
tuple_fraction /= *num_groups;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If both GROUP BY and ORDER BY are specified, we will need two
|
2005-10-15 04:49:52 +02:00
|
|
|
* levels of sort --- and, therefore, certainly need to read all the
|
|
|
|
* tuples --- unless ORDER BY is a subset of GROUP BY.
|
2005-08-28 00:13:44 +02:00
|
|
|
*/
|
|
|
|
if (parse->groupClause && parse->sortClause &&
|
|
|
|
!pathkeys_contained_in(root->sort_pathkeys, root->group_pathkeys))
|
|
|
|
tuple_fraction = 0.0;
|
|
|
|
}
|
|
|
|
else if (parse->hasAggs || root->hasHavingQual)
|
|
|
|
{
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Ungrouped aggregate will certainly want to read all the tuples, and
|
|
|
|
* it will deliver a single result row (so leave *num_groups 1).
|
2005-08-28 00:13:44 +02:00
|
|
|
*/
|
|
|
|
tuple_fraction = 0.0;
|
|
|
|
}
|
|
|
|
else if (parse->distinctClause)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Since there was no grouping or aggregation, it's reasonable to
|
2005-10-15 04:49:52 +02:00
|
|
|
* assume the UNIQUE filter has effects comparable to GROUP BY. Return
|
|
|
|
* the estimated number of output rows for use by caller. (If DISTINCT
|
|
|
|
* is used with grouping, we ignore its effects for rowcount
|
|
|
|
* estimation purposes; this amounts to assuming the grouped rows are
|
|
|
|
* distinct already.)
|
2005-08-28 00:13:44 +02:00
|
|
|
*/
|
|
|
|
List *distinctExprs;
|
|
|
|
|
|
|
|
distinctExprs = get_sortgrouplist_exprs(parse->distinctClause,
|
|
|
|
parse->targetList);
|
|
|
|
*num_groups = estimate_num_groups(root,
|
|
|
|
distinctExprs,
|
|
|
|
final_rel->rows);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Adjust tuple_fraction the same way as for GROUP BY, too.
|
|
|
|
*/
|
|
|
|
if (tuple_fraction >= 1.0)
|
|
|
|
tuple_fraction /= *num_groups;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Plain non-grouped, non-aggregated query: an absolute tuple fraction
|
|
|
|
* can be divided by the number of tuples.
|
2005-08-28 00:13:44 +02:00
|
|
|
*/
|
|
|
|
if (tuple_fraction >= 1.0)
|
|
|
|
tuple_fraction /= final_rel->rows;
|
|
|
|
}
|
2000-02-15 21:49:31 +01:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Pick out the cheapest-total path and the cheapest presorted path for
|
|
|
|
* the requested pathkeys (if there is one). We should 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.)
|
2002-11-21 01:42:20 +01:00
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* The cheapest-total path is also the one to use if grouping_planner
|
|
|
|
* decides to use hashed aggregation, so we return it separately even if
|
|
|
|
* this routine thinks the presorted path is the winner.
|
2000-02-15 21:49:31 +01:00
|
|
|
*/
|
2002-11-21 01:42:20 +01:00
|
|
|
cheapestpath = final_rel->cheapest_total_path;
|
2000-02-15 21:49:31 +01:00
|
|
|
|
2002-11-21 01:42:20 +01:00
|
|
|
sortedpath =
|
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
|
|
|
|
2002-11-21 01:42:20 +01:00
|
|
|
/* Don't return same path in both guises; just wastes effort */
|
|
|
|
if (sortedpath == cheapestpath)
|
|
|
|
sortedpath = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Forget about the presorted path if it would be cheaper to sort the
|
2005-10-15 04:49:52 +02:00
|
|
|
* cheapest-total path. Here we need consider only the behavior at the
|
|
|
|
* tuple fraction point.
|
2002-11-21 01:42:20 +01:00
|
|
|
*/
|
|
|
|
if (sortedpath)
|
|
|
|
{
|
|
|
|
Path sort_path; /* dummy for result of cost_sort */
|
|
|
|
|
|
|
|
if (root->query_pathkeys == NIL ||
|
|
|
|
pathkeys_contained_in(root->query_pathkeys,
|
|
|
|
cheapestpath->pathkeys))
|
|
|
|
{
|
|
|
|
/* No sort needed for cheapest path */
|
|
|
|
sort_path.startup_cost = cheapestpath->startup_cost;
|
|
|
|
sort_path.total_cost = cheapestpath->total_cost;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Figure cost for sorting */
|
|
|
|
cost_sort(&sort_path, root, root->query_pathkeys,
|
|
|
|
cheapestpath->total_cost,
|
|
|
|
final_rel->rows, final_rel->width);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (compare_fractional_path_costs(sortedpath, &sort_path,
|
|
|
|
tuple_fraction) > 0)
|
|
|
|
{
|
|
|
|
/* Presorted path is a loser */
|
|
|
|
sortedpath = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
*cheapest_path = cheapestpath;
|
|
|
|
*sorted_path = sortedpath;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|