1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* joinrels.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* Routines to determine which relations should be joined
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
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
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.86 2007/02/16 00:14:01 tgl Exp $
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2005-06-09 06:19:00 +02:00
|
|
|
#include "optimizer/joininfo.h"
|
1996-07-09 08:22:35 +02: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
|
|
|
|
2000-02-07 05:41:04 +01:00
|
|
|
|
2005-06-06 00:32:58 +02:00
|
|
|
static List *make_rels_by_clause_joins(PlannerInfo *root,
|
2003-08-04 02:43:34 +02:00
|
|
|
RelOptInfo *old_rel,
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *other_rels);
|
2005-06-06 00:32:58 +02:00
|
|
|
static List *make_rels_by_clauseless_joins(PlannerInfo *root,
|
2003-08-04 02:43:34 +02:00
|
|
|
RelOptInfo *old_rel,
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *other_rels);
|
2005-12-20 03:30:36 +01:00
|
|
|
static bool has_join_restriction(PlannerInfo *root, RelOptInfo *rel);
|
2000-02-07 05:41:04 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
1999-02-15 04:22:37 +01:00
|
|
|
* make_rels_by_joins
|
2000-02-07 05:41:04 +01:00
|
|
|
* Consider ways to produce join relations containing exactly 'level'
|
2000-09-12 23:07:18 +02:00
|
|
|
* jointree items. (This is one step of the dynamic-programming method
|
2000-02-07 05:41:04 +01:00
|
|
|
* embodied in make_one_rel_by_joins.) Join rel nodes for each feasible
|
2000-09-12 23:07:18 +02:00
|
|
|
* combination of lower-level rels are created and returned in a list.
|
|
|
|
* Implementation paths are created for each such joinrel, too.
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
2000-09-12 23:07:18 +02:00
|
|
|
* level: level of rels we want to make this time.
|
|
|
|
* joinrels[j], 1 <= j < level, is a list of rels containing j items.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-09-12 23:07:18 +02:00
|
|
|
List *
|
2005-06-06 00:32:58 +02:00
|
|
|
make_rels_by_joins(PlannerInfo *root, int level, List **joinrels)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
List *result_rels = NIL;
|
|
|
|
List *new_rels;
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *r;
|
2000-09-12 23:07:18 +02:00
|
|
|
int k;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-02-07 05:41:04 +01:00
|
|
|
/*
|
|
|
|
* First, consider left-sided and right-sided plans, in which rels of
|
2005-10-15 04:49:52 +02:00
|
|
|
* exactly level-1 member relations are joined against initial relations.
|
|
|
|
* We prefer to join using join clauses, but if we find a rel of level-1
|
|
|
|
* members that has no join clauses, we will generate Cartesian-product
|
|
|
|
* joins against all initial rels not already contained in it.
|
2000-02-07 05:41:04 +01:00
|
|
|
*
|
2005-10-15 04:49:52 +02:00
|
|
|
* In the first pass (level == 2), we try to join each initial rel to each
|
|
|
|
* initial rel that appears later in joinrels[1]. (The mirror-image joins
|
|
|
|
* are handled automatically by make_join_rel.) In later passes, we try
|
|
|
|
* to join rels of size level-1 from joinrels[level-1] to each initial rel
|
|
|
|
* in joinrels[1].
|
2000-02-07 05:41:04 +01:00
|
|
|
*/
|
2001-03-22 05:01:46 +01:00
|
|
|
foreach(r, joinrels[level - 1])
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1999-02-18 05:45:36 +01:00
|
|
|
RelOptInfo *old_rel = (RelOptInfo *) lfirst(r);
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *other_rels;
|
2000-02-07 05:41:04 +01:00
|
|
|
|
|
|
|
if (level == 2)
|
2000-09-12 23:07:18 +02:00
|
|
|
other_rels = lnext(r); /* only consider remaining initial
|
2000-04-12 19:17:23 +02:00
|
|
|
* rels */
|
2000-02-07 05:41:04 +01:00
|
|
|
else
|
2004-08-29 07:07:03 +02:00
|
|
|
other_rels = list_head(joinrels[1]); /* consider all initial
|
|
|
|
* rels */
|
2000-02-07 05:41:04 +01:00
|
|
|
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
if (old_rel->joininfo != NIL || old_rel->has_eclass_joins ||
|
|
|
|
has_join_restriction(root, old_rel))
|
2000-02-07 05:41:04 +01:00
|
|
|
{
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Note that if all available join clauses for this rel require
|
|
|
|
* more than one other rel, we will fail to make any joins against
|
|
|
|
* it here. In most cases that's OK; it'll be considered by
|
|
|
|
* "bushy plan" join code in a higher-level pass where we have
|
|
|
|
* those other rels collected into a join rel.
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
*
|
|
|
|
* See also the last-ditch case below.
|
2000-02-07 05:41:04 +01:00
|
|
|
*/
|
2000-09-12 23:07:18 +02:00
|
|
|
new_rels = make_rels_by_clause_joins(root,
|
|
|
|
old_rel,
|
|
|
|
other_rels);
|
2000-02-07 05:41:04 +01:00
|
|
|
}
|
|
|
|
else
|
There's a patch attached to fix gcc 2.8.x warnings, except for the
yyerror ones from bison. It also includes a few 'enhancements' to
the C programming style (which are, of course, personal).
The other patch removes the compilation of backend/lib/qsort.c, as
qsort() is a standard function in stdlib.h and can be used any
where else (and it is). It was only used in
backend/optimizer/geqo/geqo_pool.c, backend/optimizer/path/predmig.c,
and backend/storage/page/bufpage.c
> > Some or all of these changes might not be appropriate for v6.3,
since we > > are in beta testing and since they do not affect the
current functionality. > > For those cases, how about submitting
patches based on the final v6.3 > > release?
There's more to come. Please review these patches. I ran the
regression tests and they only failed where this was expected
(random, geo, etc).
Cheers,
Jeroen
1998-03-30 18:47:35 +02:00
|
|
|
{
|
1999-02-14 05:57:02 +01:00
|
|
|
/*
|
|
|
|
* Oops, we have a relation that is not joined to any other
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
* relation, either directly or by join-order restrictions.
|
|
|
|
* Cartesian product time.
|
1999-02-14 05:57:02 +01:00
|
|
|
*/
|
2000-09-12 23:07:18 +02:00
|
|
|
new_rels = make_rels_by_clauseless_joins(root,
|
|
|
|
old_rel,
|
|
|
|
other_rels);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2001-03-22 05:01:46 +01:00
|
|
|
* At levels above 2 we will generate the same joined relation in
|
|
|
|
* multiple ways --- for example (a join b) join c is the same
|
2005-10-15 04:49:52 +02:00
|
|
|
* RelOptInfo as (b join c) join a, though the second case will add a
|
|
|
|
* different set of Paths to it. To avoid making extra work for
|
|
|
|
* subsequent passes, do not enter the same RelOptInfo into our output
|
|
|
|
* list multiple times.
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
2005-07-29 00:27:02 +02:00
|
|
|
result_rels = list_concat_unique_ptr(result_rels, new_rels);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
2000-02-07 05:41:04 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Now, consider "bushy plans" in which relations of k initial rels are
|
|
|
|
* joined to relations of level-k initial rels, for 2 <= k <= level-2.
|
2000-02-07 05:41:04 +01:00
|
|
|
*
|
2000-04-12 19:17:23 +02:00
|
|
|
* We only consider bushy-plan joins for pairs of rels where there is a
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
* suitable join clause (or join order restriction), in order to avoid
|
|
|
|
* unreasonable growth of planning time.
|
2000-02-07 05:41:04 +01:00
|
|
|
*/
|
2001-03-22 05:01:46 +01:00
|
|
|
for (k = 2;; k++)
|
1999-05-25 18:15:34 +02:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
int other_level = level - k;
|
1999-08-16 04:17:58 +02:00
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Since make_join_rel(x, y) handles both x,y and y,x cases, we only
|
|
|
|
* need to go as far as the halfway point.
|
2000-02-07 05:41:04 +01:00
|
|
|
*/
|
2000-09-12 23:07:18 +02:00
|
|
|
if (k > other_level)
|
2000-02-07 05:41:04 +01:00
|
|
|
break;
|
1999-08-16 04:17:58 +02:00
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
foreach(r, joinrels[k])
|
1999-08-16 04:17:58 +02:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
RelOptInfo *old_rel = (RelOptInfo *) lfirst(r);
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *other_rels;
|
|
|
|
ListCell *r2;
|
2000-09-12 23:07:18 +02:00
|
|
|
|
2006-12-12 22:31:02 +01:00
|
|
|
/*
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
* We can ignore clauseless joins here, *except* when they
|
|
|
|
* participate in join-order restrictions --- then we might have
|
|
|
|
* to force a bushy join plan.
|
2006-12-12 22:31:02 +01:00
|
|
|
*/
|
2007-01-20 21:45:41 +01:00
|
|
|
if (old_rel->joininfo == NIL && !old_rel->has_eclass_joins &&
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
!has_join_restriction(root, old_rel))
|
2006-12-12 22:31:02 +01:00
|
|
|
continue;
|
2000-09-12 23:07:18 +02:00
|
|
|
|
|
|
|
if (k == other_level)
|
2001-03-22 05:01:46 +01:00
|
|
|
other_rels = lnext(r); /* only consider remaining rels */
|
2000-09-12 23:07:18 +02:00
|
|
|
else
|
2004-05-26 06:41:50 +02:00
|
|
|
other_rels = list_head(joinrels[other_level]);
|
2000-09-12 23:07:18 +02:00
|
|
|
|
2004-05-26 06:41:50 +02:00
|
|
|
for_each_cell(r2, other_rels)
|
1999-02-18 01:49:48 +01:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
RelOptInfo *new_rel = (RelOptInfo *) lfirst(r2);
|
2000-02-07 05:41:04 +01:00
|
|
|
|
2003-02-08 21:20:55 +01:00
|
|
|
if (!bms_overlap(old_rel->relids, new_rel->relids))
|
2000-09-12 23:07:18 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* OK, we can build a rel of the right level from this
|
2005-10-15 04:49:52 +02:00
|
|
|
* pair of rels. Do so if there is at least one usable
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
* join clause or a relevant join restriction.
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
if (have_relevant_joinclause(root, old_rel, new_rel) ||
|
|
|
|
have_join_order_restriction(root, old_rel, new_rel))
|
2000-02-07 05:41:04 +01:00
|
|
|
{
|
2005-06-09 06:19:00 +02:00
|
|
|
RelOptInfo *jrel;
|
|
|
|
|
2005-12-20 03:30:36 +01:00
|
|
|
jrel = make_join_rel(root, old_rel, new_rel);
|
2005-06-09 06:19:00 +02:00
|
|
|
/* Avoid making duplicate entries ... */
|
2005-07-29 00:27:02 +02:00
|
|
|
if (jrel)
|
|
|
|
result_rels = list_append_unique_ptr(result_rels,
|
|
|
|
jrel);
|
2000-02-07 05:41:04 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2000-04-27 20:35:04 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Last-ditch effort: if we failed to find any usable joins so far, force
|
|
|
|
* a set of cartesian-product joins to be generated. This handles the
|
|
|
|
* special case where all the available rels have join clauses but we
|
|
|
|
* cannot use any of the joins yet. An example is
|
2000-04-27 20:35:04 +02:00
|
|
|
*
|
|
|
|
* SELECT * FROM a,b,c WHERE (a.f1 + b.f2 + c.f3) = 0;
|
|
|
|
*
|
2001-03-22 05:01:46 +01:00
|
|
|
* The join clause will be usable at level 3, but at level 2 we have no
|
2005-10-15 04:49:52 +02:00
|
|
|
* choice but to make cartesian joins. We consider only left-sided and
|
|
|
|
* right-sided cartesian joins in this case (no bushy).
|
2000-04-27 20:35:04 +02:00
|
|
|
*/
|
2000-09-12 23:07:18 +02:00
|
|
|
if (result_rels == NIL)
|
2000-04-27 20:35:04 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
|
|
|
* This loop is just like the first one, except we always call
|
2000-04-27 20:35:04 +02:00
|
|
|
* make_rels_by_clauseless_joins().
|
|
|
|
*/
|
2001-03-22 05:01:46 +01:00
|
|
|
foreach(r, joinrels[level - 1])
|
2000-04-27 20:35:04 +02:00
|
|
|
{
|
|
|
|
RelOptInfo *old_rel = (RelOptInfo *) lfirst(r);
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *other_rels;
|
2000-04-27 20:35:04 +02:00
|
|
|
|
|
|
|
if (level == 2)
|
2001-03-22 05:01:46 +01:00
|
|
|
other_rels = lnext(r); /* only consider remaining initial
|
|
|
|
* rels */
|
2000-04-27 20:35:04 +02:00
|
|
|
else
|
2004-08-29 07:07:03 +02:00
|
|
|
other_rels = list_head(joinrels[1]); /* consider all initial
|
|
|
|
* rels */
|
2000-09-12 23:07:18 +02:00
|
|
|
|
|
|
|
new_rels = make_rels_by_clauseless_joins(root,
|
|
|
|
old_rel,
|
|
|
|
other_rels);
|
|
|
|
|
2005-07-29 00:27:02 +02:00
|
|
|
result_rels = list_concat_unique_ptr(result_rels, new_rels);
|
2000-04-27 20:35:04 +02:00
|
|
|
}
|
|
|
|
|
2003-12-17 18:07:48 +01:00
|
|
|
/*----------
|
2005-12-20 03:30:36 +01:00
|
|
|
* When OJs or IN clauses are involved, there may be no legal way
|
|
|
|
* to make an N-way join for some values of N. For example consider
|
2003-12-17 18:07:48 +01:00
|
|
|
*
|
|
|
|
* SELECT ... FROM t1 WHERE
|
2004-08-29 07:07:03 +02:00
|
|
|
* x IN (SELECT ... FROM t2,t3 WHERE ...) AND
|
|
|
|
* y IN (SELECT ... FROM t4,t5 WHERE ...)
|
2003-12-17 18:07:48 +01:00
|
|
|
*
|
|
|
|
* We will flatten this query to a 5-way join problem, but there are
|
|
|
|
* no 4-way joins that make_join_rel() will consider legal. We have
|
|
|
|
* to accept failure at level 4 and go on to discover a workable
|
|
|
|
* bushy plan at level 5.
|
|
|
|
*
|
2005-12-20 03:30:36 +01:00
|
|
|
* However, if there are no such clauses then make_join_rel() should
|
2003-12-17 18:07:48 +01:00
|
|
|
* never fail, and so the following sanity check is useful.
|
|
|
|
*----------
|
|
|
|
*/
|
2005-12-20 03:30:36 +01:00
|
|
|
if (result_rels == NIL &&
|
|
|
|
root->oj_info_list == NIL && root->in_info_list == NIL)
|
2003-07-25 02:01:09 +02:00
|
|
|
elog(ERROR, "failed to build any %d-way joins", level);
|
2000-04-27 20:35:04 +02:00
|
|
|
}
|
2000-09-12 23:07:18 +02:00
|
|
|
|
|
|
|
return result_rels;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2000-02-07 05:41:04 +01:00
|
|
|
* make_rels_by_clause_joins
|
|
|
|
* Build joins between the given relation 'old_rel' and other relations
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
* that participate in join clauses that 'old_rel' also participates in
|
|
|
|
* (or participate in join-order restrictions with it).
|
2000-09-12 23:07:18 +02:00
|
|
|
* The join rel nodes are returned in a list.
|
2000-02-07 05:41:04 +01:00
|
|
|
*
|
|
|
|
* 'old_rel' is the relation entry for the relation to be joined
|
2004-05-26 06:41:50 +02:00
|
|
|
* 'other_rels': the first cell in a linked list containing the other
|
|
|
|
* rels to be considered for joining
|
2000-02-07 05:41:04 +01:00
|
|
|
*
|
2000-09-12 23:07:18 +02:00
|
|
|
* Currently, this is only used with initial rels in other_rels, but it
|
2005-06-09 06:19:00 +02:00
|
|
|
* will work for joining to joinrels too.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
Fix GEQO to work again in CVS tip, by being more careful about memory
allocation in best_inner_indexscan(). While at it, simplify GEQO's
interface to the main planner --- make_join_rel() offers exactly the
API it really wants, whereas calling make_rels_by_clause_joins() and
make_rels_by_clauseless_joins() required jumping through hoops.
Rewrite gimme_tree for clarity (sometimes iteration is much better than
recursion), and approximately halve GEQO's runtime by recognizing that
tours of the forms (a,b,c,d,...) and (b,a,c,d,...) are equivalent
because of symmetry in make_join_rel().
2002-12-16 22:30:30 +01:00
|
|
|
static List *
|
2005-06-06 00:32:58 +02:00
|
|
|
make_rels_by_clause_joins(PlannerInfo *root,
|
2000-02-07 05:41:04 +01:00
|
|
|
RelOptInfo *old_rel,
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *other_rels)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
List *result = NIL;
|
2005-06-09 06:19:00 +02:00
|
|
|
ListCell *l;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2005-06-09 06:19:00 +02:00
|
|
|
for_each_cell(l, other_rels)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-06-09 06:19:00 +02:00
|
|
|
RelOptInfo *other_rel = (RelOptInfo *) lfirst(l);
|
1999-08-16 04:17:58 +02:00
|
|
|
|
2005-06-09 06:19:00 +02:00
|
|
|
if (!bms_overlap(old_rel->relids, other_rel->relids) &&
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
(have_relevant_joinclause(root, old_rel, other_rel) ||
|
|
|
|
have_join_order_restriction(root, old_rel, other_rel)))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-06-09 06:19:00 +02:00
|
|
|
RelOptInfo *jrel;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2005-12-20 03:30:36 +01:00
|
|
|
jrel = make_join_rel(root, old_rel, other_rel);
|
2005-06-09 06:19:00 +02:00
|
|
|
if (jrel)
|
|
|
|
result = lcons(jrel, result);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2000-02-07 05:41:04 +01:00
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2000-02-07 05:41:04 +01:00
|
|
|
* make_rels_by_clauseless_joins
|
|
|
|
* Given a relation 'old_rel' and a list of other relations
|
|
|
|
* 'other_rels', create a join relation between 'old_rel' and each
|
|
|
|
* member of 'other_rels' that isn't already included in 'old_rel'.
|
2000-09-12 23:07:18 +02:00
|
|
|
* The join rel nodes are returned in a list.
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
2000-02-07 05:41:04 +01:00
|
|
|
* 'old_rel' is the relation entry for the relation to be joined
|
2004-05-26 06:41:50 +02:00
|
|
|
* 'other_rels': the first cell of a linked list containing the
|
|
|
|
* other rels to be considered for joining
|
1999-08-16 04:17:58 +02:00
|
|
|
*
|
2000-09-12 23:07:18 +02:00
|
|
|
* Currently, this is only used with initial rels in other_rels, but it would
|
2000-02-07 05:41:04 +01:00
|
|
|
* work for joining to joinrels too.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
Fix GEQO to work again in CVS tip, by being more careful about memory
allocation in best_inner_indexscan(). While at it, simplify GEQO's
interface to the main planner --- make_join_rel() offers exactly the
API it really wants, whereas calling make_rels_by_clause_joins() and
make_rels_by_clauseless_joins() required jumping through hoops.
Rewrite gimme_tree for clarity (sometimes iteration is much better than
recursion), and approximately halve GEQO's runtime by recognizing that
tours of the forms (a,b,c,d,...) and (b,a,c,d,...) are equivalent
because of symmetry in make_join_rel().
2002-12-16 22:30:30 +01:00
|
|
|
static List *
|
2005-06-06 00:32:58 +02:00
|
|
|
make_rels_by_clauseless_joins(PlannerInfo *root,
|
2000-02-07 05:41:04 +01:00
|
|
|
RelOptInfo *old_rel,
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *other_rels)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-09-12 23:07:18 +02:00
|
|
|
List *result = NIL;
|
2004-05-26 06:41:50 +02:00
|
|
|
ListCell *i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2004-05-26 06:41:50 +02:00
|
|
|
for_each_cell(i, other_rels)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-02-07 05:41:04 +01:00
|
|
|
RelOptInfo *other_rel = (RelOptInfo *) lfirst(i);
|
1999-05-25 18:15:34 +02:00
|
|
|
|
2003-02-08 21:20:55 +01:00
|
|
|
if (!bms_overlap(other_rel->relids, old_rel->relids))
|
2000-12-18 07:50:51 +01:00
|
|
|
{
|
|
|
|
RelOptInfo *jrel;
|
|
|
|
|
2005-12-20 03:30:36 +01:00
|
|
|
jrel = make_join_rel(root, old_rel, other_rel);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2000-12-18 07:50:51 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* As long as given other_rels are distinct, don't need to test to
|
|
|
|
* see if jrel is already part of output list.
|
2000-12-18 07:50:51 +01:00
|
|
|
*/
|
2003-01-20 19:55:07 +01:00
|
|
|
if (jrel)
|
|
|
|
result = lcons(jrel, result);
|
2000-12-18 07:50:51 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
2000-02-07 05:41:04 +01:00
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2000-02-07 05:41:04 +01:00
|
|
|
* make_join_rel
|
|
|
|
* Find or create a join RelOptInfo that represents the join of
|
|
|
|
* the two given rels, and add to it path information for paths
|
|
|
|
* created with the two rels as outer and inner rel.
|
|
|
|
* (The join rel may already contain paths generated from other
|
|
|
|
* pairs of rels that add up to the same set of base rels.)
|
2003-01-20 19:55:07 +01:00
|
|
|
*
|
2005-12-20 03:30:36 +01:00
|
|
|
* NB: will return NULL if attempted join is not valid. This can happen
|
|
|
|
* when working with outer joins, or with IN clauses that have been turned
|
|
|
|
* into joins.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
Fix GEQO to work again in CVS tip, by being more careful about memory
allocation in best_inner_indexscan(). While at it, simplify GEQO's
interface to the main planner --- make_join_rel() offers exactly the
API it really wants, whereas calling make_rels_by_clause_joins() and
make_rels_by_clauseless_joins() required jumping through hoops.
Rewrite gimme_tree for clarity (sometimes iteration is much better than
recursion), and approximately halve GEQO's runtime by recognizing that
tours of the forms (a,b,c,d,...) and (b,a,c,d,...) are equivalent
because of symmetry in make_join_rel().
2002-12-16 22:30:30 +01:00
|
|
|
RelOptInfo *
|
2005-12-20 03:30:36 +01:00
|
|
|
make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2003-02-08 21:20:55 +01:00
|
|
|
Relids joinrelids;
|
2005-12-20 03:30:36 +01:00
|
|
|
JoinType jointype;
|
|
|
|
bool is_valid_inner;
|
2000-04-12 19:17:23 +02:00
|
|
|
RelOptInfo *joinrel;
|
|
|
|
List *restrictlist;
|
2005-12-20 03:30:36 +01:00
|
|
|
ListCell *l;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-01-20 19:55:07 +01:00
|
|
|
/* We should never try to join two overlapping sets of rels. */
|
2003-02-08 21:20:55 +01:00
|
|
|
Assert(!bms_overlap(rel1->relids, rel2->relids));
|
2003-01-20 19:55:07 +01:00
|
|
|
|
|
|
|
/* Construct Relids set that identifies the joinrel. */
|
2003-02-08 21:20:55 +01:00
|
|
|
joinrelids = bms_union(rel1->relids, rel2->relids);
|
2003-01-20 19:55:07 +01:00
|
|
|
|
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* If we have any outer joins, the proposed join might be illegal; and in
|
|
|
|
* any case we have to determine its join type. Scan the OJ list for
|
|
|
|
* conflicts.
|
2003-01-20 19:55:07 +01:00
|
|
|
*/
|
2005-12-20 03:30:36 +01:00
|
|
|
jointype = JOIN_INNER; /* default if no match to an OJ */
|
|
|
|
is_valid_inner = true;
|
2003-01-20 19:55:07 +01:00
|
|
|
|
2005-12-20 03:30:36 +01:00
|
|
|
foreach(l, root->oj_info_list)
|
|
|
|
{
|
|
|
|
OuterJoinInfo *ojinfo = (OuterJoinInfo *) lfirst(l);
|
2003-01-20 19:55:07 +01:00
|
|
|
|
2005-12-20 03:30:36 +01:00
|
|
|
/*
|
|
|
|
* This OJ is not relevant unless its RHS overlaps the proposed join.
|
|
|
|
* (Check this first as a fast path for dismissing most irrelevant OJs
|
|
|
|
* quickly.)
|
|
|
|
*/
|
|
|
|
if (!bms_overlap(ojinfo->min_righthand, joinrelids))
|
|
|
|
continue;
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2005-12-20 03:30:36 +01:00
|
|
|
/*
|
|
|
|
* Also, not relevant if proposed join is fully contained within RHS
|
|
|
|
* (ie, we're still building up the RHS).
|
|
|
|
*/
|
|
|
|
if (bms_is_subset(joinrelids, ojinfo->min_righthand))
|
|
|
|
continue;
|
2004-03-08 18:20:17 +01:00
|
|
|
|
2005-12-20 03:30:36 +01:00
|
|
|
/*
|
|
|
|
* Also, not relevant if OJ is already done within either input.
|
|
|
|
*/
|
|
|
|
if (bms_is_subset(ojinfo->min_lefthand, rel1->relids) &&
|
|
|
|
bms_is_subset(ojinfo->min_righthand, rel1->relids))
|
|
|
|
continue;
|
|
|
|
if (bms_is_subset(ojinfo->min_lefthand, rel2->relids) &&
|
|
|
|
bms_is_subset(ojinfo->min_righthand, rel2->relids))
|
|
|
|
continue;
|
2003-08-04 02:43:34 +02:00
|
|
|
|
2005-12-20 03:30:36 +01:00
|
|
|
/*
|
|
|
|
* If one input contains min_lefthand and the other contains
|
|
|
|
* min_righthand, then we can perform the OJ at this join.
|
|
|
|
*
|
|
|
|
* Barf if we get matches to more than one OJ (is that possible?)
|
|
|
|
*/
|
|
|
|
if (bms_is_subset(ojinfo->min_lefthand, rel1->relids) &&
|
|
|
|
bms_is_subset(ojinfo->min_righthand, rel2->relids))
|
|
|
|
{
|
2003-01-20 19:55:07 +01:00
|
|
|
if (jointype != JOIN_INNER)
|
|
|
|
{
|
2005-12-20 03:30:36 +01:00
|
|
|
/* invalid join path */
|
2003-02-08 21:20:55 +01:00
|
|
|
bms_free(joinrelids);
|
2003-01-20 19:55:07 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
2005-12-20 03:30:36 +01:00
|
|
|
jointype = ojinfo->is_full_join ? JOIN_FULL : JOIN_LEFT;
|
|
|
|
}
|
|
|
|
else if (bms_is_subset(ojinfo->min_lefthand, rel2->relids) &&
|
|
|
|
bms_is_subset(ojinfo->min_righthand, rel1->relids))
|
|
|
|
{
|
|
|
|
if (jointype != JOIN_INNER)
|
2003-01-20 19:55:07 +01:00
|
|
|
{
|
|
|
|
/* invalid join path */
|
2003-02-08 21:20:55 +01:00
|
|
|
bms_free(joinrelids);
|
2003-01-20 19:55:07 +01:00
|
|
|
return NULL;
|
|
|
|
}
|
2005-12-20 03:30:36 +01:00
|
|
|
jointype = ojinfo->is_full_join ? JOIN_FULL : JOIN_RIGHT;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*----------
|
|
|
|
* Otherwise, the proposed join overlaps the RHS but isn't
|
|
|
|
* a valid implementation of this OJ. It might still be
|
2007-02-13 03:31:03 +01:00
|
|
|
* a legal join, however. If both inputs overlap the RHS,
|
|
|
|
* assume that it's OK. Since the inputs presumably got past
|
|
|
|
* this function's checks previously, they can't overlap the
|
|
|
|
* LHS and their violations of the RHS boundary must represent
|
|
|
|
* OJs that have been determined to commute with this one.
|
|
|
|
* We have to allow this to work correctly in cases like
|
|
|
|
* (a LEFT JOIN (b JOIN (c LEFT JOIN d)))
|
|
|
|
* when the c/d join has been determined to commute with the join
|
|
|
|
* to a, and hence d is not part of min_righthand for the upper
|
|
|
|
* join. It should be legal to join b to c/d but this will appear
|
|
|
|
* as a violation of the upper join's RHS.
|
|
|
|
* Furthermore, if one input overlaps the RHS and the other does
|
|
|
|
* not, we should still allow the join if it is a valid
|
|
|
|
* implementation of some other OJ. We have to allow this to
|
|
|
|
* support the associative identity
|
|
|
|
* (a LJ b on Pab) LJ c ON Pbc = a LJ (b LJ c ON Pbc) on Pab
|
2005-12-20 03:30:36 +01:00
|
|
|
* since joining B directly to C violates the lower OJ's RHS.
|
|
|
|
* We assume that make_outerjoininfo() set things up correctly
|
2007-02-13 03:31:03 +01:00
|
|
|
* so that we'll only match to some OJ if the join is valid.
|
|
|
|
* Set flag here to check at bottom of loop.
|
2005-12-20 03:30:36 +01:00
|
|
|
*----------
|
|
|
|
*/
|
2007-02-13 03:31:03 +01:00
|
|
|
if (bms_overlap(rel1->relids, ojinfo->min_righthand) &&
|
|
|
|
bms_overlap(rel2->relids, ojinfo->min_righthand))
|
|
|
|
{
|
|
|
|
/* seems OK */
|
|
|
|
Assert(!bms_overlap(joinrelids, ojinfo->min_lefthand));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
is_valid_inner = false;
|
2005-12-20 03:30:36 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fail if violated some OJ's RHS and didn't match to another OJ */
|
|
|
|
if (jointype == JOIN_INNER && !is_valid_inner)
|
|
|
|
{
|
|
|
|
/* invalid join path */
|
|
|
|
bms_free(joinrelids);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Similarly, if we are implementing IN clauses as joins, check for
|
|
|
|
* illegal join path and detect whether we need a non-default join type.
|
|
|
|
*/
|
|
|
|
foreach(l, root->in_info_list)
|
|
|
|
{
|
|
|
|
InClauseInfo *ininfo = (InClauseInfo *) lfirst(l);
|
|
|
|
|
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* This IN clause is not relevant unless its RHS overlaps the proposed
|
|
|
|
* join. (Check this first as a fast path for dismissing most
|
|
|
|
* irrelevant INs quickly.)
|
2005-12-20 03:30:36 +01:00
|
|
|
*/
|
|
|
|
if (!bms_overlap(ininfo->righthand, joinrelids))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
2006-10-04 02:30:14 +02:00
|
|
|
* If we are still building the IN clause's RHS, then this IN clause
|
|
|
|
* isn't relevant yet.
|
2005-12-20 03:30:36 +01:00
|
|
|
*/
|
|
|
|
if (bms_is_subset(joinrelids, ininfo->righthand))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Cannot join if proposed join contains rels not in the RHS *and*
|
|
|
|
* contains only part of the RHS. We must build the complete RHS
|
|
|
|
* (subselect's join) before it can be joined to rels outside the
|
|
|
|
* subselect.
|
|
|
|
*/
|
|
|
|
if (!bms_is_subset(ininfo->righthand, joinrelids))
|
|
|
|
{
|
|
|
|
bms_free(joinrelids);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* At this point we are considering a join of the IN's RHS to some
|
|
|
|
* other rel(s).
|
|
|
|
*
|
|
|
|
* If we already joined IN's RHS to any other rels in either input
|
|
|
|
* path, then this join is not constrained (the necessary work was
|
|
|
|
* done at the lower level where that join occurred).
|
|
|
|
*/
|
|
|
|
if (bms_is_subset(ininfo->righthand, rel1->relids) &&
|
|
|
|
!bms_equal(ininfo->righthand, rel1->relids))
|
|
|
|
continue;
|
|
|
|
if (bms_is_subset(ininfo->righthand, rel2->relids) &&
|
|
|
|
!bms_equal(ininfo->righthand, rel2->relids))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* JOIN_IN technique will work if outerrel includes LHS and innerrel
|
|
|
|
* is exactly RHS; conversely JOIN_REVERSE_IN handles RHS/LHS.
|
|
|
|
*
|
|
|
|
* JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS; conversely
|
|
|
|
* JOIN_UNIQUE_INNER will work if innerrel is exactly RHS.
|
|
|
|
*
|
|
|
|
* But none of these will work if we already found an OJ or another IN
|
|
|
|
* that needs to trigger here.
|
|
|
|
*/
|
|
|
|
if (jointype != JOIN_INNER)
|
|
|
|
{
|
|
|
|
bms_free(joinrelids);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
if (bms_is_subset(ininfo->lefthand, rel1->relids) &&
|
|
|
|
bms_equal(ininfo->righthand, rel2->relids))
|
|
|
|
jointype = JOIN_IN;
|
|
|
|
else if (bms_is_subset(ininfo->lefthand, rel2->relids) &&
|
|
|
|
bms_equal(ininfo->righthand, rel1->relids))
|
|
|
|
jointype = JOIN_REVERSE_IN;
|
|
|
|
else if (bms_equal(ininfo->righthand, rel1->relids))
|
|
|
|
jointype = JOIN_UNIQUE_OUTER;
|
|
|
|
else if (bms_equal(ininfo->righthand, rel2->relids))
|
|
|
|
jointype = JOIN_UNIQUE_INNER;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* invalid join path */
|
|
|
|
bms_free(joinrelids);
|
|
|
|
return NULL;
|
2003-01-20 19:55:07 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Find or build the join RelOptInfo, and compute the restrictlist that
|
|
|
|
* goes with this particular joining.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2003-01-20 19:55:07 +01:00
|
|
|
joinrel = build_join_rel(root, joinrelids, rel1, rel2, jointype,
|
|
|
|
&restrictlist);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-02-07 05:41:04 +01:00
|
|
|
/*
|
2000-09-12 23:07:18 +02:00
|
|
|
* Consider paths using each rel as both outer and inner.
|
2000-02-07 05:41:04 +01:00
|
|
|
*/
|
2000-09-12 23:07:18 +02:00
|
|
|
switch (jointype)
|
|
|
|
{
|
|
|
|
case JOIN_INNER:
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel1, rel2, JOIN_INNER,
|
|
|
|
restrictlist);
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel2, rel1, JOIN_INNER,
|
|
|
|
restrictlist);
|
|
|
|
break;
|
|
|
|
case JOIN_LEFT:
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel1, rel2, JOIN_LEFT,
|
|
|
|
restrictlist);
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel2, rel1, JOIN_RIGHT,
|
|
|
|
restrictlist);
|
|
|
|
break;
|
|
|
|
case JOIN_FULL:
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel1, rel2, JOIN_FULL,
|
|
|
|
restrictlist);
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel2, rel1, JOIN_FULL,
|
|
|
|
restrictlist);
|
|
|
|
break;
|
|
|
|
case JOIN_RIGHT:
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel1, rel2, JOIN_RIGHT,
|
|
|
|
restrictlist);
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel2, rel1, JOIN_LEFT,
|
|
|
|
restrictlist);
|
|
|
|
break;
|
2003-01-20 19:55:07 +01:00
|
|
|
case JOIN_IN:
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel1, rel2, JOIN_IN,
|
|
|
|
restrictlist);
|
|
|
|
/* REVERSE_IN isn't supported by joinpath.c */
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel1, rel2, JOIN_UNIQUE_INNER,
|
|
|
|
restrictlist);
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel2, rel1, JOIN_UNIQUE_OUTER,
|
|
|
|
restrictlist);
|
|
|
|
break;
|
|
|
|
case JOIN_REVERSE_IN:
|
|
|
|
/* REVERSE_IN isn't supported by joinpath.c */
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel2, rel1, JOIN_IN,
|
|
|
|
restrictlist);
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel1, rel2, JOIN_UNIQUE_OUTER,
|
|
|
|
restrictlist);
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel2, rel1, JOIN_UNIQUE_INNER,
|
|
|
|
restrictlist);
|
|
|
|
break;
|
|
|
|
case JOIN_UNIQUE_OUTER:
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel1, rel2, JOIN_UNIQUE_OUTER,
|
|
|
|
restrictlist);
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel2, rel1, JOIN_UNIQUE_INNER,
|
|
|
|
restrictlist);
|
|
|
|
break;
|
|
|
|
case JOIN_UNIQUE_INNER:
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel1, rel2, JOIN_UNIQUE_INNER,
|
|
|
|
restrictlist);
|
|
|
|
add_paths_to_joinrel(root, joinrel, rel2, rel1, JOIN_UNIQUE_OUTER,
|
|
|
|
restrictlist);
|
|
|
|
break;
|
2000-09-12 23:07:18 +02:00
|
|
|
default:
|
2003-07-25 02:01:09 +02:00
|
|
|
elog(ERROR, "unrecognized join type: %d",
|
2000-09-12 23:07:18 +02:00
|
|
|
(int) jointype);
|
|
|
|
break;
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-02-08 21:20:55 +01:00
|
|
|
bms_free(joinrelids);
|
2003-01-20 19:55:07 +01:00
|
|
|
|
2000-02-07 05:41:04 +01:00
|
|
|
return joinrel;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
Restructure code that is responsible for ensuring that clauseless joins are
considered when it is necessary to do so because of a join-order restriction
(that is, an outer-join or IN-subselect construct). The former coding was a
bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario
Weilguni's recent bug report. His specific problem was that an IN could be
turned into a "clauseless" join due to constant-propagation removing the IN's
joinclause, and if the IN's subselect involved more than one relation and
there was more than one such IN linking to the same upper relation, then the
only valid join orders involve "bushy" plans but we would fail to consider the
specific paths needed to get there. (See the example case added to the join
regression test.) On examining the code I wonder if there weren't some other
problem cases too; in particular it seems that GEQO was defending against a
different set of corner cases than the main planner was. There was also an
efficiency problem, in that when we did realize we needed a clauseless join
because of an IN, we'd consider clauseless joins against every other relation
whether this was sensible or not. It seems a better design is to use the
outer-join and in-clause lists as a backup heuristic, just as the rule of
joining only where there are joinclauses is a heuristic: we'll join two
relations if they have a usable joinclause *or* this might be necessary to
satisfy an outer-join or IN-clause join order restriction. I refactored the
code to have just one place considering this instead of three, and made sure
that it covered all the cases that any of them had been considering.
Backpatch as far as 8.1 (which has only the IN-clause form of the disease).
By rights 8.0 and 7.4 should have the bug too, but they accidentally fail
to fail, because the joininfo structure used in those releases preserves some
memory of there having once been a joinclause between the inner and outer
sides of an IN, and so it leads the code in the right direction anyway.
I'll be conservative and not touch them.
2007-02-16 01:14:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* have_join_order_restriction
|
|
|
|
* Detect whether the two relations should be joined to satisfy
|
|
|
|
* a join-order restriction arising from outer joins or IN clauses.
|
|
|
|
*
|
|
|
|
* In practice this is always used with have_relevant_joinclause(), and so
|
|
|
|
* could be merged with that function, but it seems clearer to separate the
|
|
|
|
* two concerns. We need these tests because there are degenerate cases where
|
|
|
|
* a clauseless join must be performed to satisfy join-order restrictions.
|
|
|
|
*
|
|
|
|
* Note: this is only a problem if one side of a degenerate outer join
|
|
|
|
* contains multiple rels, or a clauseless join is required within an IN's
|
|
|
|
* RHS; else we will find a join path via the "last ditch" case in
|
|
|
|
* make_rels_by_joins(). We could dispense with this test if we were willing
|
|
|
|
* to try bushy plans in the "last ditch" case, but that seems much less
|
|
|
|
* efficient.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
have_join_order_restriction(PlannerInfo *root,
|
|
|
|
RelOptInfo *rel1, RelOptInfo *rel2)
|
|
|
|
{
|
|
|
|
ListCell *l;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It's possible that the rels correspond to the left and right sides
|
|
|
|
* of a degenerate outer join, that is, one with no joinclause mentioning
|
|
|
|
* the non-nullable side; in which case we should force the join to occur.
|
|
|
|
*
|
|
|
|
* Also, the two rels could represent a clauseless join that has to be
|
|
|
|
* completed to build up the LHS or RHS of an outer join.
|
|
|
|
*/
|
|
|
|
foreach(l, root->oj_info_list)
|
|
|
|
{
|
|
|
|
OuterJoinInfo *ojinfo = (OuterJoinInfo *) lfirst(l);
|
|
|
|
|
|
|
|
/* ignore full joins --- other mechanisms handle them */
|
|
|
|
if (ojinfo->is_full_join)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Can we perform the OJ with these rels? */
|
|
|
|
if (bms_is_subset(ojinfo->min_lefthand, rel1->relids) &&
|
|
|
|
bms_is_subset(ojinfo->min_righthand, rel2->relids))
|
|
|
|
return true;
|
|
|
|
if (bms_is_subset(ojinfo->min_lefthand, rel2->relids) &&
|
|
|
|
bms_is_subset(ojinfo->min_righthand, rel1->relids))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Might we need to join these rels to complete the RHS? We have
|
|
|
|
* to use "overlap" tests since either rel might include a lower OJ
|
|
|
|
* that has been proven to commute with this one.
|
|
|
|
*/
|
|
|
|
if (bms_overlap(ojinfo->min_righthand, rel1->relids) &&
|
|
|
|
bms_overlap(ojinfo->min_righthand, rel2->relids))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/* Likewise for the LHS. */
|
|
|
|
if (bms_overlap(ojinfo->min_lefthand, rel1->relids) &&
|
|
|
|
bms_overlap(ojinfo->min_lefthand, rel2->relids))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Similarly, we need to allow a join that completes a degenerate
|
|
|
|
* IN-clause, or one that builds up its LHS or RHS.
|
|
|
|
*/
|
|
|
|
foreach(l, root->in_info_list)
|
|
|
|
{
|
|
|
|
InClauseInfo *ininfo = (InClauseInfo *) lfirst(l);
|
|
|
|
|
|
|
|
/* Can we perform the IN with these rels? */
|
|
|
|
if (bms_is_subset(ininfo->lefthand, rel1->relids) &&
|
|
|
|
bms_is_subset(ininfo->righthand, rel2->relids))
|
|
|
|
return true;
|
|
|
|
if (bms_is_subset(ininfo->lefthand, rel2->relids) &&
|
|
|
|
bms_is_subset(ininfo->righthand, rel1->relids))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Might we need to join these rels to complete the RHS? It's
|
|
|
|
* probably overkill to test "overlap", since we never join part of an
|
|
|
|
* IN's RHS to anything else, but may as well keep the coding similar
|
|
|
|
* to the OJ case.
|
|
|
|
*/
|
|
|
|
if (bms_overlap(ininfo->righthand, rel1->relids) &&
|
|
|
|
bms_overlap(ininfo->righthand, rel2->relids))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/* Likewise for the LHS. */
|
|
|
|
if (bms_overlap(ininfo->lefthand, rel1->relids) &&
|
|
|
|
bms_overlap(ininfo->lefthand, rel2->relids))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* has_join_restriction
|
|
|
|
* Detect whether the specified relation has join-order restrictions
|
|
|
|
* due to being inside an outer join or an IN (sub-SELECT).
|
|
|
|
*
|
|
|
|
* Essentially, this tests whether have_join_order_restriction() could
|
|
|
|
* succeed with this rel and some other one.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
has_join_restriction(PlannerInfo *root, RelOptInfo *rel)
|
|
|
|
{
|
|
|
|
ListCell *l;
|
|
|
|
|
|
|
|
foreach(l, root->oj_info_list)
|
|
|
|
{
|
|
|
|
OuterJoinInfo *ojinfo = (OuterJoinInfo *) lfirst(l);
|
|
|
|
|
|
|
|
/* ignore full joins --- other mechanisms preserve their ordering */
|
|
|
|
if (ojinfo->is_full_join)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* ignore if OJ is already contained in rel */
|
|
|
|
if (bms_is_subset(ojinfo->min_lefthand, rel->relids) &&
|
|
|
|
bms_is_subset(ojinfo->min_righthand, rel->relids))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* restricted if it overlaps LHS or RHS, but doesn't contain OJ */
|
|
|
|
if (bms_overlap(ojinfo->min_lefthand, rel->relids) ||
|
|
|
|
bms_overlap(ojinfo->min_righthand, rel->relids))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach(l, root->in_info_list)
|
|
|
|
{
|
|
|
|
InClauseInfo *ininfo = (InClauseInfo *) lfirst(l);
|
|
|
|
|
|
|
|
/* ignore if IN is already contained in rel */
|
|
|
|
if (bms_is_subset(ininfo->lefthand, rel->relids) &&
|
|
|
|
bms_is_subset(ininfo->righthand, rel->relids))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* restricted if it overlaps LHS or RHS, but doesn't contain IN */
|
|
|
|
if (bms_overlap(ininfo->lefthand, rel->relids) ||
|
|
|
|
bms_overlap(ininfo->righthand, rel->relids))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|