doc: vacuum full, fillfactor, and "extra space"

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: doc: vacuum full, fillfactor, and "extra space"
Date: 2019-12-27 02:31:34
Message-ID: 20191227023134.GC12890@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I started writing this patch to avoid the possibly-misleading phrase: "with no
extra space" (since it's expected to typically take ~2x space, or 1x "extra"
space).

But the original phrase "with no extra space" seems to be wrong anyway, since
it actually follows fillfactor, so say that. Possibly should be backpatched.

diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml
index ec2503d..9757352 100644
--- a/doc/src/sgml/ref/vacuum.sgml
+++ b/doc/src/sgml/ref/vacuum.sgml
@@ -75,10 +75,16 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ <replaceable class="paramet
with normal reading and writing of the table, as an exclusive lock
is not obtained. However, extra space is not returned to the operating
system (in most cases); it's just kept available for re-use within the
- same table. <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.
+ same table.
+ </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

Attachment Content-Type Size
v1-0001-doc-VACUUM-FULL-separate-paragraph-fillfactor.patch text/x-diff 1.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2019-12-27 02:32:03 Re: Calling PLpgSQL function with composite type fails with an error: "ERROR: could not open relation with OID ..."
Previous Message Tomas Vondra 2019-12-27 02:24:01 Re: [HACKERS] Block level parallel vacuum