pgsql: Allow vacuums to report oldestxmin

Started by Simon Riggsalmost 9 years ago10 messages

simon@2ndQuadrant.com

almost 9 years ago

Allow vacuums to report oldestxmin

Allow VACUUM and Autovacuum to report the oldestxmin value they
used while cleaning tables, helping to make better sense out of
the other statistics we report in various cases.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9eb344faf54a849898d9be012ddfa8204cfeb57c

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Masahiko Sawada

sawada.mshk@gmail.com

almost 9 years ago

In reply to: Simon Riggs (#1)

1 attachment(s)

Re: pgsql: Allow vacuums to report oldestxmin

On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Allow vacuums to report oldestxmin

Allow VACUUM and Autovacuum to report the oldestxmin value they
used while cleaning tables, helping to make better sense out of
the other statistics we report in various cases.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9eb344faf54a849898d9be012ddfa8204cfeb57c

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

Should we change the example in vacuum.sgml file as well? Attached patch.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachments:

fix_vacuum_example_in_doc.patchapplication/octet-stream; name=fix_vacuum_example_in_doc.patchDownload

diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml
index 543ebcf..1f836a4 100644
--- a/doc/src/sgml/ref/vacuum.sgml
+++ b/doc/src/sgml/ref/vacuum.sgml
@@ -271,7 +271,7 @@ CPU: user: 0.09 s, system: 0.01 s, elapsed: 0.59 s.
 INFO:  "onek": removed 3000 tuples in 108 pages
 DETAIL:  CPU: user: 0.06 s, system: 0.01 s, elapsed: 0.07 s.
 INFO:  "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages
-DETAIL:  0 dead tuples cannot be removed yet.
+DETAIL:  0 dead tuples cannot be removed yet, oldest xmin: 556
 There were 0 unused item pointers.
 Skipped 0 pages due to buffer pins.
 0 pages are entirely empty.

Fujii Masao

masao.fujii@gmail.com

almost 9 years ago

In reply to: Masahiko Sawada (#2)

Re: pgsql: Allow vacuums to report oldestxmin

On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Allow vacuums to report oldestxmin

Allow VACUUM and Autovacuum to report the oldestxmin value they
used while cleaning tables, helping to make better sense out of
the other statistics we report in various cases.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9eb344faf54a849898d9be012ddfa8204cfeb57c

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

Should we change the example in vacuum.sgml file as well? Attached patch.

"tuples" in the above should be "row versions"?
We should review not only this line but also all the lines in the example
of VERBOSE output, I think.

Regards,

--
Fujii Masao

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Masahiko Sawada

sawada.mshk@gmail.com

almost 9 years ago

In reply to: Fujii Masao (#3)

1 attachment(s)

Re: pgsql: Allow vacuums to report oldestxmin

On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Allow vacuums to report oldestxmin

Allow VACUUM and Autovacuum to report the oldestxmin value they
used while cleaning tables, helping to make better sense out of
the other statistics we report in various cases.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9eb344faf54a849898d9be012ddfa8204cfeb57c

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

Should we change the example in vacuum.sgml file as well? Attached patch.

"tuples" in the above should be "row versions"?
We should review not only this line but also all the lines in the example
of VERBOSE output, I think.

Right. These verbose log messages are out of date. I ran
VACUUM(VERBOSE, ANALYZE) with same scenario as current example as
possible. Attached patch updates verbose log messages.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachments:

fix_vacuum_example_in_doc_v2.patchapplication/octet-stream; name=fix_vacuum_example_in_doc_v2.patchDownload

diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml
index 8ec5b40..b4c9bd5 100644
--- a/doc/src/sgml/ref/vacuum.sgml
+++ b/doc/src/sgml/ref/vacuum.sgml
@@ -252,32 +252,42 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">
 <programlisting>
 regression=# VACUUM (VERBOSE, ANALYZE) onek;
 INFO:  vacuuming "public.onek"
-INFO:  index "onek_unique1" now contains 1000 tuples in 14 pages
-DETAIL:  3000 index tuples were removed.
+INFO:  scanned index "onek_unique1" to remove 3000 row versions
+DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
+INFO:  scanned index "onek_unique2" to remove 3000 row versions
+DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
+INFO:  scanned index "onek_hundred" to remove 3000 row versions
+DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
+INFO:  scanned index "onek_stringu1" to remove 3000 row versions
+DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
+INFO:  "onek": removed 3000 row versions in 104 pages
+DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
+INFO:  index "onek_unique1" now contains 1000 row versions in 17 pages
+DETAIL:  3000 index row versions were removed.
+10 index pages have been deleted, 0 are currently reusable.
+CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
+INFO:  index "onek_unique2" now contains 1000 row versions in 16 pages
+DETAIL:  3000 index row versions were removed.
 0 index pages have been deleted, 0 are currently reusable.
-CPU: user: 0.08 s, system: 0.01 s, elapsed: 0.18 s.
-INFO:  index "onek_unique2" now contains 1000 tuples in 16 pages
-DETAIL:  3000 index tuples were removed.
+CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
+INFO:  index "onek_hundred" now contains 1000 row versions in 16 pages
+DETAIL:  3000 index row versions were removed.
 0 index pages have been deleted, 0 are currently reusable.
-CPU: user: 0.07 s, system: 0.00 s, elapsed: 0.23 s.
-INFO:  index "onek_hundred" now contains 1000 tuples in 13 pages
-DETAIL:  3000 index tuples were removed.
+CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
+INFO:  index "onek_stringu1" now contains 1000 row versions in 17 pages
+DETAIL:  3000 index row versions were removed.
 0 index pages have been deleted, 0 are currently reusable.
-CPU: user: 0.08 s, system: 0.01 s, elapsed: 0.17 s.
-INFO:  index "onek_stringu1" now contains 1000 tuples in 48 pages
-DETAIL:  3000 index tuples were removed.
-0 index pages have been deleted, 0 are currently reusable.
-CPU: user: 0.09 s, system: 0.01 s, elapsed: 0.59 s.
-INFO:  "onek": removed 3000 tuples in 108 pages
-DETAIL:  CPU: user: 0.06 s, system: 0.01 s, elapsed: 0.07 s.
-INFO:  "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages
-DETAIL:  0 dead tuples cannot be removed yet.
+CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
+INFO:  "onek": found 3000 removable, 1000 nonremovable row versions in 138 out of 138 pages
+DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 19590
 There were 0 unused item pointers.
 Skipped 0 pages due to buffer pins, 0 frozen pages.
 0 pages are entirely empty.
-CPU: user: 0.39 s, system: 0.07 s, elapsed: 1.56 s.
+CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.01 s.
+INFO:  "onek": truncated 138 to 35 pages
+DETAIL:  CPU: user: 0.03 s, system: 0.00 s, elapsed: 0.03 s.
 INFO:  analyzing "public.onek"
-INFO:  "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows
+INFO:  "onek": scanned 35 of 35 pages, containing 1000 live rows and 0 dead rows; 1000 rows in sample, 1000 estimated total rows
 VACUUM
 </programlisting></para>
  </refsect1>

Masahiko Sawada

sawada.mshk@gmail.com

almost 9 years ago

In reply to: Masahiko Sawada (#4)

Re: pgsql: Allow vacuums to report oldestxmin

On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Allow vacuums to report oldestxmin

Allow VACUUM and Autovacuum to report the oldestxmin value they
used while cleaning tables, helping to make better sense out of
the other statistics we report in various cases.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9eb344faf54a849898d9be012ddfa8204cfeb57c

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

Should we change the example in vacuum.sgml file as well? Attached patch.

"tuples" in the above should be "row versions"?
We should review not only this line but also all the lines in the example
of VERBOSE output, I think.

Right. These verbose log messages are out of date. I ran
VACUUM(VERBOSE, ANALYZE) with same scenario as current example as
possible. Attached patch updates verbose log messages.

Surprisingly the changes "tuples" -> "row versions" in vacuumlazy.c is
introduced by commit feb4f44d296b88b7f0723f4a4f3945a371276e0b in 2003.
If this patch is applied, it should back-patch to all supported
branches.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Fujii Masao

masao.fujii@gmail.com

almost 9 years ago

In reply to: Masahiko Sawada (#5)

Re: [COMMITTERS] pgsql: Allow vacuums to report oldestxmin

On Tue, Mar 28, 2017 at 1:06 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Allow vacuums to report oldestxmin

Allow VACUUM and Autovacuum to report the oldestxmin value they
used while cleaning tables, helping to make better sense out of
the other statistics we report in various cases.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9eb344faf54a849898d9be012ddfa8204cfeb57c

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

Should we change the example in vacuum.sgml file as well? Attached patch.

"tuples" in the above should be "row versions"?
We should review not only this line but also all the lines in the example
of VERBOSE output, I think.

Right. These verbose log messages are out of date. I ran
VACUUM(VERBOSE, ANALYZE) with same scenario as current example as
possible. Attached patch updates verbose log messages.

Surprisingly the changes "tuples" -> "row versions" in vacuumlazy.c is
introduced by commit feb4f44d296b88b7f0723f4a4f3945a371276e0b in 2003.

This is the evidence that no one cares about the details of VACUUM VERBOSE
output example. So I'm tempted to simplify the example (please see the
attached patch) instead of keeping updating the example.

If this patch is applied, it should back-patch to all supported
branches.

Not sure if it's worth back-patching that.

Regards,

--
Fujii Masao

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Fujii Masao

masao.fujii@gmail.com

almost 9 years ago

In reply to: Fujii Masao (#6)

1 attachment(s)

Re: [COMMITTERS] pgsql: Allow vacuums to report oldestxmin

On Wed, Mar 29, 2017 at 1:32 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Tue, Mar 28, 2017 at 1:06 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Allow vacuums to report oldestxmin

Allow VACUUM and Autovacuum to report the oldestxmin value they
used while cleaning tables, helping to make better sense out of
the other statistics we report in various cases.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9eb344faf54a849898d9be012ddfa8204cfeb57c

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

Should we change the example in vacuum.sgml file as well? Attached patch.

"tuples" in the above should be "row versions"?
We should review not only this line but also all the lines in the example
of VERBOSE output, I think.

Right. These verbose log messages are out of date. I ran
VACUUM(VERBOSE, ANALYZE) with same scenario as current example as
possible. Attached patch updates verbose log messages.

Surprisingly the changes "tuples" -> "row versions" in vacuumlazy.c is
introduced by commit feb4f44d296b88b7f0723f4a4f3945a371276e0b in 2003.

This is the evidence that no one cares about the details of VACUUM VERBOSE
output example. So I'm tempted to simplify the example (please see the
attached patch) instead of keeping updating the example.

Patch attached.

Regards,

--
Fujii Masao

Attachments:

vacuum-example.patchapplication/octet-stream; name=vacuum-example.patchDownload

*** a/doc/src/sgml/ref/vacuum.sgml
--- b/doc/src/sgml/ref/vacuum.sgml
***************
*** 246,284 **** VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">
    <title>Examples</title>
  
    <para>
!    The following is an example from running <command>VACUUM</command> on a
!    table in the regression database:
  
  <programlisting>
! regression=# VACUUM (VERBOSE, ANALYZE) onek;
! INFO:  vacuuming "public.onek"
! INFO:  index "onek_unique1" now contains 1000 tuples in 14 pages
! DETAIL:  3000 index tuples were removed.
! 0 index pages have been deleted, 0 are currently reusable.
! CPU: user: 0.08 s, system: 0.01 s, elapsed: 0.18 s.
! INFO:  index "onek_unique2" now contains 1000 tuples in 16 pages
! DETAIL:  3000 index tuples were removed.
! 0 index pages have been deleted, 0 are currently reusable.
! CPU: user: 0.07 s, system: 0.00 s, elapsed: 0.23 s.
! INFO:  index "onek_hundred" now contains 1000 tuples in 13 pages
! DETAIL:  3000 index tuples were removed.
! 0 index pages have been deleted, 0 are currently reusable.
! CPU: user: 0.08 s, system: 0.01 s, elapsed: 0.17 s.
! INFO:  index "onek_stringu1" now contains 1000 tuples in 48 pages
! DETAIL:  3000 index tuples were removed.
! 0 index pages have been deleted, 0 are currently reusable.
! CPU: user: 0.09 s, system: 0.01 s, elapsed: 0.59 s.
! INFO:  "onek": removed 3000 tuples in 108 pages
! DETAIL:  CPU: user: 0.06 s, system: 0.01 s, elapsed: 0.07 s.
! INFO:  "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages
! DETAIL:  0 dead tuples cannot be removed yet.
! There were 0 unused item pointers.
! Skipped 0 pages due to buffer pins, 0 frozen pages.
! 0 pages are entirely empty.
! CPU: user: 0.39 s, system: 0.07 s, elapsed: 1.56 s.
! INFO:  analyzing "public.onek"
! INFO:  "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows
! VACUUM
  </programlisting></para>
   </refsect1>
  
--- 246,256 ----
    <title>Examples</title>
  
    <para>
!    To clean a single table <literal>onek</literal>, analyze it for
!    the optimizer and print a detailed vacuum activity report:
  
  <programlisting>
! VACUUM (VERBOSE, ANALYZE) onek;
  </programlisting></para>
   </refsect1>

Alvaro Herrera

alvherre@2ndquadrant.com

almost 9 years ago

In reply to: Fujii Masao (#6)

Re: [COMMITTERS] pgsql: Allow vacuums to report oldestxmin

Fujii Masao wrote:

This is the evidence that no one cares about the details of VACUUM VERBOSE
output example. So I'm tempted to simplify the example (please see the
attached patch) instead of keeping updating the example.

Agreed.

If this patch is applied, it should back-patch to all supported
branches.

Not sure if it's worth back-patching that.

I see no reason to keep it in back branches either.

--
ï¿½lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Masahiko Sawada

sawada.mshk@gmail.com

almost 9 years ago

In reply to: Fujii Masao (#6)

Re: pgsql: Allow vacuums to report oldestxmin

On Wed, Mar 29, 2017 at 1:32 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Tue, Mar 28, 2017 at 1:06 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Allow vacuums to report oldestxmin

Allow VACUUM and Autovacuum to report the oldestxmin value they
used while cleaning tables, helping to make better sense out of
the other statistics we report in various cases.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9eb344faf54a849898d9be012ddfa8204cfeb57c

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

Should we change the example in vacuum.sgml file as well? Attached patch.

"tuples" in the above should be "row versions"?
We should review not only this line but also all the lines in the example
of VERBOSE output, I think.

Right. These verbose log messages are out of date. I ran
VACUUM(VERBOSE, ANALYZE) with same scenario as current example as
possible. Attached patch updates verbose log messages.

Surprisingly the changes "tuples" -> "row versions" in vacuumlazy.c is
introduced by commit feb4f44d296b88b7f0723f4a4f3945a371276e0b in 2003.

This is the evidence that no one cares about the details of VACUUM VERBOSE
output example. So I'm tempted to simplify the example (please see the
attached patch) instead of keeping updating the example.

Yes. I agree.

If this patch is applied, it should back-patch to all supported
branches.

Not sure if it's worth back-patching that.

Regards,

--
Fujii Masao

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#10

Fujii Masao

masao.fujii@gmail.com

almost 9 years ago

In reply to: Masahiko Sawada (#9)

Re: pgsql: Allow vacuums to report oldestxmin

On Wed, Mar 29, 2017 at 3:31 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Wed, Mar 29, 2017 at 1:32 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Tue, Mar 28, 2017 at 1:06 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:

On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Allow vacuums to report oldestxmin

Allow VACUUM and Autovacuum to report the oldestxmin value they
used while cleaning tables, helping to make better sense out of
the other statistics we report in various cases.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/9eb344faf54a849898d9be012ddfa8204cfeb57c

Modified Files
--------------
src/backend/commands/vacuumlazy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

Should we change the example in vacuum.sgml file as well? Attached patch.

"tuples" in the above should be "row versions"?
We should review not only this line but also all the lines in the example
of VERBOSE output, I think.

Right. These verbose log messages are out of date. I ran
VACUUM(VERBOSE, ANALYZE) with same scenario as current example as
possible. Attached patch updates verbose log messages.

Surprisingly the changes "tuples" -> "row versions" in vacuumlazy.c is
introduced by commit feb4f44d296b88b7f0723f4a4f3945a371276e0b in 2003.

This is the evidence that no one cares about the details of VACUUM VERBOSE
output example. So I'm tempted to simplify the example (please see the
attached patch) instead of keeping updating the example.

Yes. I agree.

Pushed. I back-patched to all supported versions according to
Alvaro's comment upthread.

Regards,

--
Fujii Masao

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers