diff options
| author | Bruce Momjian <bruce@momjian.us> | 2014-05-06 11:26:27 -0400 |
|---|---|---|
| committer | Bruce Momjian <bruce@momjian.us> | 2014-05-06 11:26:27 -0400 |
| commit | 0b44914c21a008bb2f0764672eb6b15310431b3e (patch) | |
| tree | 0dccfe5e855aebe7160470bcfcb37597611d981c /src/backend/optimizer/util/plancat.c | |
| parent | 17b04a15806d8e8b4cc3013244f4837c02d6baf4 (diff) | |
Remove tabs after spaces in C comments
This was not changed in HEAD, but will be done later as part of a
pgindent run. Future pgindent runs will also do this.
Report by Tom Lane
Backpatch through all supported branches, but not HEAD
Diffstat (limited to 'src/backend/optimizer/util/plancat.c')
| -rw-r--r-- | src/backend/optimizer/util/plancat.c | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c index d6056e55a71..c5dccef1e27 100644 --- a/src/backend/optimizer/util/plancat.c +++ b/src/backend/optimizer/util/plancat.c @@ -404,12 +404,12 @@ estimate_rel_size(Relation rel, int32 *attr_widths, * minimum size estimate of 10 pages. The idea here is to avoid * assuming a newly-created table is really small, even if it * currently is, because that may not be true once some data gets - * loaded into it. Once a vacuum or analyze cycle has been done + * loaded into it. Once a vacuum or analyze cycle has been done * on it, it's more reasonable to believe the size is somewhat * stable. * * (Note that this is only an issue if the plan gets cached and - * used again after the table has been filled. What we're trying + * used again after the table has been filled. What we're trying * to avoid is using a nestloop-type plan on a table that has * grown substantially since the plan was made. Normally, * autovacuum/autoanalyze will occur once enough inserts have @@ -418,7 +418,7 @@ estimate_rel_size(Relation rel, int32 *attr_widths, * such as temporary tables.) * * We approximate "never vacuumed" by "has relpages = 0", which - * means this will also fire on genuinely empty relations. Not + * means this will also fire on genuinely empty relations. Not * great, but fortunately that's a seldom-seen case in the real * world, and it shouldn't degrade the quality of the plan too * much anyway to err in this direction. @@ -763,7 +763,7 @@ relation_excluded_by_constraints(PlannerInfo *root, return false; /* - * OK to fetch the constraint expressions. Include "col IS NOT NULL" + * OK to fetch the constraint expressions. Include "col IS NOT NULL" * expressions for attnotnull columns, in case we can refute those. */ constraint_pred = get_relation_constraints(root, rte->relid, rel, true); @@ -811,7 +811,7 @@ relation_excluded_by_constraints(PlannerInfo *root, * Exception: if there are any dropped columns, we punt and return NIL. * Ideally we would like to handle the dropped-column case too. However this * creates problems for ExecTypeFromTL, which may be asked to build a tupdesc - * for a tlist that includes vars of no-longer-existent types. In theory we + * for a tlist that includes vars of no-longer-existent types. In theory we * could dig out the required info from the pg_attribute entries of the * relation, but that data is not readily available to ExecTypeFromTL. * For now, we don't apply the physical-tlist optimization when there are |