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 |
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 |