database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-14 08:21:07 +03:00
Code Activity

Pgindent run before 9.1 beta2.

Browse Source
This commit is contained in:
Bruce Momjian
2011-06-09 14:32:50 -04:00
parent adf43b2b36
commit 6560407c7d
92 changed files with 644 additions and 620 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
src/backend/optimizer/path/costsize.c
View File

@ -2687,7 +2687,7 @@ cost_qual_eval_walker(Node *node, cost_qual_eval_context *context)
* evaluation of AND/OR? Probably *not*, because that would make the
* results depend on the clause ordering, and we are not in any position
* to expect that the current ordering of the clauses is the one that's
* going to end up being used. The above per-RestrictInfo caching would
* going to end up being used. The above per-RestrictInfo caching would
* not mix well with trying to re-order clauses anyway.
*/
if (IsA(node, FuncExpr))

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

@ -953,7 +953,7 @@ is_dummy_rel(RelOptInfo *rel)
* dummy.
*
* Also, when called during GEQO join planning, we are in a short-lived
* memory context. We must make sure that the dummy path attached to a
* memory context. We must make sure that the dummy path attached to a
* baserel survives the GEQO cycle, else the baserel is trashed for future
* GEQO cycles. On the other hand, when we are marking a joinrel during GEQO,
* we don't want the dummy path to clutter the main planning context. Upshot