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

8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list

Browse Source 
provided by Andrew.
This commit is contained in:
Bruce Momjian
2009-06-11 14:49:15 +00:00
parent 4e86efb4e5
commit d747140279
654 changed files with 11900 additions and 11387 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
src/backend/optimizer/path/equivclass.c
View File

@@ -10,7 +10,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/equivclass.c,v 1.18 2009/04/19 19:46:33 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/equivclass.c,v 1.19 2009/06/11 14:48:58 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@@ -438,9 +438,9 @@ get_eclass_for_sort_expr(PlannerInfo *root,
/*
* add_eq_member doesn't check for volatile functions, set-returning
* functions, aggregates, or window functions, but such could appear
* in sort expressions; so we have to check whether its const-marking
* was correct.
* functions, aggregates, or window functions, but such could appear in
* sort expressions; so we have to check whether its const-marking was
* correct.
*/
if (newec->ec_has_const)
{
@@ -563,11 +563,11 @@ generate_base_implied_equalities_const(PlannerInfo *root,
ListCell *lc;
/*
* In the trivial case where we just had one "var = const" clause,
* push the original clause back into the main planner machinery. There
* is nothing to be gained by doing it differently, and we save the
* effort to re-build and re-analyze an equality clause that will be
* exactly equivalent to the old one.
* In the trivial case where we just had one "var = const" clause, push
* the original clause back into the main planner machinery. There is
* nothing to be gained by doing it differently, and we save the effort to
* re-build and re-analyze an equality clause that will be exactly
* equivalent to the old one.
*/
if (list_length(ec->ec_members) == 2 &&
list_length(ec->ec_sources) == 1)
@@ -1166,7 +1166,7 @@ create_join_clause(PlannerInfo *root,
*
* Outer join clauses that are marked outerjoin_delayed are special: this
* condition means that one or both VARs might go to null due to a lower
* outer join. We can still push a constant through the clause, but only
* outer join. We can still push a constant through the clause, but only
* if its operator is strict; and we *have to* throw the clause back into
* regular joinclause processing. By keeping the strict join clause,
* we ensure that any null-extended rows that are mistakenly generated due
@@ -1816,11 +1816,11 @@ have_relevant_eclass_joinclause(PlannerInfo *root,
* path to look through ec_sources. Checking the members anyway is OK
* as a possibly-overoptimistic heuristic.
*
* We don't test ec_has_const either, even though a const eclass
* won't generate real join clauses. This is because if we had
* "WHERE a.x = b.y and a.x = 42", it is worth considering a join
* between a and b, since the join result is likely to be small even
* though it'll end up being an unqualified nestloop.
* We don't test ec_has_const either, even though a const eclass won't
* generate real join clauses. This is because if we had "WHERE a.x =
* b.y and a.x = 42", it is worth considering a join between a and b,
* since the join result is likely to be small even though it'll end
* up being an unqualified nestloop.
*/
/* Needn't scan if it couldn't contain members from each rel */
@@ -1890,11 +1890,11 @@ has_relevant_eclass_joinclause(PlannerInfo *root, RelOptInfo *rel1)
* path to look through ec_sources. Checking the members anyway is OK
* as a possibly-overoptimistic heuristic.
*
* We don't test ec_has_const either, even though a const eclass
* won't generate real join clauses. This is because if we had
* "WHERE a.x = b.y and a.x = 42", it is worth considering a join
* between a and b, since the join result is likely to be small even
* though it'll end up being an unqualified nestloop.
* We don't test ec_has_const either, even though a const eclass won't
* generate real join clauses. This is because if we had "WHERE a.x =
* b.y and a.x = 42", it is worth considering a join between a and b,
* since the join result is likely to be small even though it'll end
* up being an unqualified nestloop.
*/
/* Needn't scan if it couldn't contain members from each rel */