database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-18 17:42:25 +03:00
Code Activity

Tighten up join ordering rules to account for recent more-careful analysis

Browse Source 
of the associativity of antijoins.  Also improve optimizer/README discussion
of outer join ordering rules.
This commit is contained in:
Tom Lane
2009-02-27 22:41:38 +00:00
parent 5c4ca3b632
commit 75c85bd199
3 changed files with 38 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
src/backend/optimizer/path/joinrels.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.98 2009/02/19 20:32:45 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.99 2009/02/27 22:41:37 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -185,7 +185,7 @@ join_search_one_level(PlannerInfo *root, int level, List **joinrels)
* 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
* cannot use any of those clauses yet. An example is
*
* SELECT * FROM a,b,c WHERE (a.f1 + b.f2 + c.f3) = 0;
*
@ -737,7 +737,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
*
* 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
* two concerns. We need this test 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