Horton

Re: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Robert Haas <robertmhaas@gmail.com>, David Steele <david@pgmasters.net>, Andres Freund <andres@anarazel.de>, "Bossart, Nathan" <bossartn@amazon.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Michael Paquier <michael@paquier.xyz>, Julien Rouhaud <rjuju123@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-04-04T11:19:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add TRUNCATE parameter to VACUUM.

  2. Add vacuum_truncate reloption.

  3. Allow VACUUM to be run with index cleanup disabled.

On Thu, Apr 4, 2019 at 1:26 PM Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
>
> From: Fujii Masao [mailto:masao.fujii@gmail.com]
> > reloption for TOAST is also required?
>
> # I've come back to the office earlier than planned...
>
> Hm, there's no reason to not provide toast.vacuum_shrink_enabled.  Done with the attached patch.
>

Thank you for updating the patch!

+    <term><literal>vacuum_shrink_enabled</literal>,
<literal>toast.vacuum_shrink_enabled</literal>
(<type>boolean</type>)</term>
+    <listitem>
+     <para>
+     Enables or disables shrinking the table when it's vacuumed.
+     This also applies to autovacuum.
+     The default is true.  If true, VACUUM frees empty pages at the
end of the table.

"VACUUM" needs <command> or "vacuum" is more appropriate here?

+     Shrinking the table requires <literal>ACCESS EXCLUSIVE</literal>
lock on the table.
+     It can take non-negligible time when the shared buffer is large.
Besides, <literal>ACCESS EXCLUSIVE</literal>
+     lock could lead to query cancellation on the standby server.
+     If the workload is likely to reuse the freed space soon
+     (e.g., UPDATE-heavy, or new rows will be added after deleting
+     old rows), setting this parameter to false makes sense to avoid
unnecessary shrinking.
+     </para>
+    </listitem>
+   </varlistentry>

The format of the documentation of new option is a bit weird. Could it
be possible to adjust it around 80 characters per line like other
description?

I'm not sure the consensus we got here but we don't make the vacuum
command option for this?

Regards,

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