Rebased against 40d964ec997f64227bc0ff5e058dc4a5770a70a9
>From b9f10d21de62354d953e388642fcdfc6d97a4a47 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@telsasoft.com>
Date: Thu, 26 Dec 2019 18:54:28 -0600
Subject: [PATCH v2] doc: VACUUM FULL: separate paragraph; fillfactor
FILLFACTOR seems to apply here. Also, "no extra space" was confusing since it
could be read to mean "requires zero extra space", when actually it will always
require extra space, usually approximately the size of the table.
---
doc/src/sgml/ref/vacuum.sgml | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml
index 404febb..ab1b8c2 100644
--- a/doc/src/sgml/ref/vacuum.sgml
+++ b/doc/src/sgml/ref/vacuum.sgml
@@ -79,11 +79,16 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ <replaceable class="paramet
same table. It also allows us to leverage multiple CPUs in order to process
indexes. This feature is known as <firstterm>parallel vacuum</firstterm>.
To disable this feature, one can use <literal>PARALLEL</literal> option and
- specify parallel workers as zero. <command>VACUUM FULL</command> rewrites
- the entire contents of the table into a new disk file with no extra space,
- allowing unused space to be returned to the operating system. This form is
- much slower and requires an exclusive lock on each table while it is being
- processed.
+ specify parallel workers as zero.
+ </para>
+
+ <para>
+ <command>VACUUM FULL</command> rewrites the entire contents of the table
+ into a new file on disk with internal space left available as determined by
+ <literal>fillfactor</literal>. If the table includes many dead tuples from
+ updates/deletes, this allows unused space to be returned to the operating
+ system. This form is much slower and requires an exclusive lock on each
+ table while it is being processed.
</para>
<para>
--
2.7.4
