summaryrefslogtreecommitdiff
path: root/src/backend/optimizer/plan/planagg.c
diff options
context:
space:
mode:
authorBruce Momjian <bruce@momjian.us>2014-05-06 11:26:26 -0400
committerBruce Momjian <bruce@momjian.us>2014-05-06 11:26:26 -0400
commit2616a5d300e5bb5a2838d2a065afa3740e08727f (patch)
tree5939408c63409abda810217fe812749a5da7345b /src/backend/optimizer/plan/planagg.c
parente0070a6858cfcd2c4129dfa93bc042d6d86732c8 (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/plan/planagg.c')
-rw-r--r--src/backend/optimizer/plan/planagg.c8
1 files changed, 4 insertions, 4 deletions
diff --git a/src/backend/optimizer/plan/planagg.c b/src/backend/optimizer/plan/planagg.c
index 88a6c99ea50..a7f950a4f64 100644
--- a/src/backend/optimizer/plan/planagg.c
+++ b/src/backend/optimizer/plan/planagg.c
@@ -10,9 +10,9 @@
* ORDER BY col ASC/DESC
* LIMIT 1)
* Given a suitable index on tab.col, this can be much faster than the
- * generic scan-all-the-rows aggregation plan. We can handle multiple
+ * generic scan-all-the-rows aggregation plan. We can handle multiple
* MIN/MAX aggregates by generating multiple subqueries, and their
- * orderings can be different. However, if the query contains any
+ * orderings can be different. However, if the query contains any
* non-optimizable aggregates, there's no point since we'll have to
* scan all the rows anyway.
*
@@ -125,7 +125,7 @@ preprocess_minmax_aggregates(PlannerInfo *root, List *tlist)
/*
* Scan the tlist and HAVING qual to find all the aggregates and verify
- * all are MIN/MAX aggregates. Stop as soon as we find one that isn't.
+ * all are MIN/MAX aggregates. Stop as soon as we find one that isn't.
*/
aggs_list = NIL;
if (find_minmax_aggs_walker((Node *) tlist, &aggs_list))
@@ -160,7 +160,7 @@ preprocess_minmax_aggregates(PlannerInfo *root, List *tlist)
* We can use either an ordering that gives NULLS FIRST or one that
* gives NULLS LAST; furthermore there's unlikely to be much
* performance difference between them, so it doesn't seem worth
- * costing out both ways if we get a hit on the first one. NULLS
+ * costing out both ways if we get a hit on the first one. NULLS
* FIRST is more likely to be available if the operator is a
* reverse-sort operator, so try that first if reverse.
*/