From: Robert Haas <rhaas@postgresql.org>
Date: Thu, 22 Jun 2017 17:35:39 +0000 (-0400)
Subject: Update out-of-date comment in vacuumlazy.c
X-Git-Tag: REL_10_BETA2~86
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2a6db5eba69c0d6c842360f836cadd20e6cd9a0c;p=thirdparty%2Fpostgresql.git

Update out-of-date comment in vacuumlazy.c

Commit 15c121b3ed7eb2f290e19533e41ccca734d23574 seems to have
overlooked the need to trim this part of the comment.

Pavan Deolasee

Discussion: http://postgr.es/m/CABOikdPq_9+cWRNZ0RLKTwuZyj=uL85X=Usifa-CbPee1ZCM5A@mail.gmail.com
---

diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
index 1951aa94fb1..881c7356db3 100644
--- a/src/backend/commands/vacuumlazy.c
+++ b/src/backend/commands/vacuumlazy.c
@@ -4,11 +4,10 @@
  *	  Concurrent ("lazy") vacuuming.
  *
  *
- * The major space usage for LAZY VACUUM is storage for the array of dead
- * tuple TIDs, with the next biggest need being storage for per-disk-page
- * free space info.  We want to ensure we can vacuum even the very largest
- * relations with finite memory space usage.  To do that, we set upper bounds
- * on the number of tuples and pages we will keep track of at once.
+ * The major space usage for LAZY VACUUM is storage for the array of dead tuple
+ * TIDs.  We want to ensure we can vacuum even the very largest relations with
+ * finite memory space usage.  To do that, we set upper bounds on the number of
+ * tuples we will keep track of at once.
  *
  * We are willing to use at most maintenance_work_mem (or perhaps
  * autovacuum_work_mem) memory space to keep track of dead tuples.  We