|
8 | 8 | *
|
9 | 9 | *
|
10 | 10 | * IDENTIFICATION
|
11 |
| - * $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.150 2009/02/27 00:06:27 tgl Exp $ |
| 11 | + * $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.151 2009/03/26 17:15:35 tgl Exp $ |
12 | 12 | *
|
13 | 13 | *-------------------------------------------------------------------------
|
14 | 14 | */
|
@@ -1480,9 +1480,20 @@ create_hashjoin_path(PlannerInfo *root,
|
1480 | 1480 | pathnode->jpath.outerjoinpath = outer_path;
|
1481 | 1481 | pathnode->jpath.innerjoinpath = inner_path;
|
1482 | 1482 | pathnode->jpath.joinrestrictinfo = restrict_clauses;
|
1483 |
| - /* A hashjoin never has pathkeys, since its ordering is unpredictable */ |
| 1483 | + /* |
| 1484 | + * A hashjoin never has pathkeys, since its output ordering is |
| 1485 | + * unpredictable due to possible batching. XXX If the inner relation is |
| 1486 | + * small enough, we could instruct the executor that it must not batch, |
| 1487 | + * 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.) |
| 1493 | + */ |
1484 | 1494 | pathnode->jpath.path.pathkeys = NIL;
|
1485 | 1495 | pathnode->path_hashclauses = hashclauses;
|
| 1496 | + /* cost_hashjoin will fill in pathnode->num_batches */ |
1486 | 1497 |
|
1487 | 1498 | cost_hashjoin(pathnode, root, sjinfo);
|
1488 | 1499 |
|
|
0 commit comments