|
8 | 8 | * |
9 | 9 | * |
10 | 10 | * IDENTIFICATION |
11 | | - * $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.97 2009/01/01 17:23:44 momjian Exp $ |
| 11 | + * $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.98 2009/02/19 20:32:45 tgl Exp $ |
12 | 12 | * |
13 | 13 | *------------------------------------------------------------------------- |
14 | 14 | */ |
@@ -424,9 +424,27 @@ join_is_legal(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2, |
424 | 424 | create_unique_path(root,rel2,rel2->cheapest_total_path, |
425 | 425 | sjinfo)!=NULL) |
426 | 426 | { |
427 | | -/* |
| 427 | +/*---------- |
428 | 428 | * For a semijoin, we can join the RHS to anything else by |
429 | 429 | * unique-ifying the RHS (if the RHS can be unique-ified). |
| 430 | + * We will only get here if we have the full RHS but less |
| 431 | + * than min_lefthand on the LHS. |
| 432 | + * |
| 433 | + * The reason to consider such a join path is exemplified by |
| 434 | + *SELECT ... FROM a,b WHERE (a.x,b.y) IN (SELECT c1,c2 FROM c) |
| 435 | + * If we insist on doing this as a semijoin we will first have |
| 436 | + * to form the cartesian product of A*B. But if we unique-ify |
| 437 | + * C then the semijoin becomes a plain innerjoin and we can join |
| 438 | + * in any order, eg C to A and then to B. When C is much smaller |
| 439 | + * than A and B this can be a huge win. So we allow C to be |
| 440 | + * joined to just A or just B here, and then make_join_rel has |
| 441 | + * to handle the case properly. |
| 442 | + * |
| 443 | + * Note that actually we'll allow unique-ified C to be joined to |
| 444 | + * some other relation D here, too. That is legal, if usually not |
| 445 | + * very sane, and this routine is only concerned with legality not |
| 446 | + * with whether the join is good strategy. |
| 447 | + *---------- |
430 | 448 | */ |
431 | 449 | if (match_sjinfo) |
432 | 450 | return false;/* invalid join path */ |
@@ -648,8 +666,10 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2) |
648 | 666 | break; |
649 | 667 | caseJOIN_SEMI: |
650 | 668 | /* |
651 | | - * Do these steps only if we actually have a regular semijoin, |
652 | | - * as opposed to a case where we should unique-ify the RHS. |
| 669 | + * We might have a normal semijoin, or a case where we don't have |
| 670 | + * enough rels to do the semijoin but can unique-ify the RHS and |
| 671 | + * then do an innerjoin (see comments in join_is_legal). In the |
| 672 | + * latter case we can't apply JOIN_SEMI joining. |
653 | 673 | */ |
654 | 674 | if (bms_is_subset(sjinfo->min_lefthand,rel1->relids)&& |
655 | 675 | bms_is_subset(sjinfo->min_righthand,rel2->relids)) |
|