11
* $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.151 2009/03/26 17:15:35 tgl Exp $
11
* $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.152 2009/06/11 14:48:59 momjian Exp $
13
13
*-------------------------------------------------------------------------
797
797
in_operators = NIL;
798
798
uniq_exprs = NIL;
799
799
all_btree = true;
800
all_hash = enable_hashagg; /* don't consider hash if not enabled */
800
all_hash = enable_hashagg; /* don't consider hash if not enabled */
801
801
foreach(lc, sjinfo->join_quals)
803
803
OpExpr *op = (OpExpr *) lfirst(lc);
904
904
goto no_unique_path;
907
* If we get here, we can unique-ify using at least one of sorting
908
* and hashing. Start building the result Path object.
907
* If we get here, we can unique-ify using at least one of sorting and
908
* hashing. Start building the result Path object.
910
910
pathnode = makeNode(UniquePath);
975
* Charge one cpu_operator_cost per comparison per input tuple.
976
* We assume all columns get compared at most of the tuples. (XXX
975
* Charge one cpu_operator_cost per comparison per input tuple. We
976
* assume all columns get compared at most of the tuples. (XXX
977
977
* probably this is an overestimate.) This should agree with
1404
1404
* selected as the input of a mergejoin, and they don't support
1405
1405
* mark/restore at present.
1407
* Note: Sort supports mark/restore, so no materialize is really needed
1408
* in that case; but one may be desirable anyway to optimize the sort.
1409
* However, since we aren't representing the sort step separately in
1410
* the Path tree, we can't explicitly represent the materialize either.
1411
* So that case is not handled here. Instead, cost_mergejoin has to
1412
* factor in the cost and create_mergejoin_plan has to add the plan node.
1407
* Note: Sort supports mark/restore, so no materialize is really needed in
1408
* that case; but one may be desirable anyway to optimize the sort.
1409
* However, since we aren't representing the sort step separately in the
1410
* Path tree, we can't explicitly represent the materialize either. So
1411
* that case is not handled here. Instead, cost_mergejoin has to factor
1412
* in the cost and create_mergejoin_plan has to add the plan node.
1414
1414
if (innersortkeys == NIL &&
1415
1415
!ExecSupportsMarkRestore(inner_path->pathtype))
1419
1419
mpath = (Path *) create_material_path(inner_path->parent, inner_path);
1422
* We expect the materialize won't spill to disk (it could only do
1423
* so if there were a whole lot of duplicate tuples, which is a case
1424
* cost_mergejoin will avoid choosing anyway). Therefore
1425
* cost_material's cost estimate is bogus and we should charge
1426
* just cpu_tuple_cost per tuple. (Keep this estimate in sync with
1427
* similar ones in cost_mergejoin and create_mergejoin_plan.)
1422
* We expect the materialize won't spill to disk (it could only do so
1423
* if there were a whole lot of duplicate tuples, which is a case
1424
* cost_mergejoin will avoid choosing anyway). Therefore
1425
* cost_material's cost estimate is bogus and we should charge just
1426
* cpu_tuple_cost per tuple. (Keep this estimate in sync with similar
1427
* ones in cost_mergejoin and create_mergejoin_plan.)
1429
1429
mpath->startup_cost = inner_path->startup_cost;
1430
1430
mpath->total_cost = inner_path->total_cost;
1480
1480
pathnode->jpath.outerjoinpath = outer_path;
1481
1481
pathnode->jpath.innerjoinpath = inner_path;
1482
1482
pathnode->jpath.joinrestrictinfo = restrict_clauses;
1484
1485
* A hashjoin never has pathkeys, since its output ordering is
1485
* unpredictable due to possible batching. XXX If the inner relation is
1486
* unpredictable due to possible batching. XXX If the inner relation is
1486
1487
* small enough, we could instruct the executor that it must not batch,
1487
1488
* and then we could assume that the output inherits the outer relation's
1488
* ordering, which might save a sort step. However there is considerable
1489
* downside if our estimate of the inner relation size is badly off.
1490
* For the moment we don't risk it. (Note also that if we wanted to take
1491
* this seriously, joinpath.c would have to consider many more paths for
1492
* the outer rel than it does now.)
1489
* ordering, which might save a sort step. However there is considerable
1490
* downside if our estimate of the inner relation size is badly off. For
1491
* the moment we don't risk it. (Note also that if we wanted to take this
1492
* seriously, joinpath.c would have to consider many more paths for the
1493
* outer rel than it does now.)
1494
1495
pathnode->jpath.path.pathkeys = NIL;
1495
1496
pathnode->path_hashclauses = hashclauses;
added
removed
src/backend/optimizer/util/pathnode.c
