Re: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>,
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>,
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-04T13:06:47Z
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 →
-
Add TRUNCATE parameter to VACUUM.
- b84dbc8eb80b 12.0 landed
-
Add vacuum_truncate reloption.
- 119dcfad988d 12.0 landed
-
Allow VACUUM to be run with index cleanup disabled.
- a96c41feec6b 12.0 cited
On Thu, Apr 4, 2019 at 1:23 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > 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! +1! > + <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? also, the documentation should point out that freeing is not guaranteed. Something like + The default is true. If true, VACUUM will try to free empty pages at the end of the table. > I'm not sure the consensus we got here but we don't make the vacuum > command option for this? I don't think here's a clear consensus, but my personal vote is to add it, with SHRINK_TABLE = [ force_on | force_off | default ] (unless a better proposal has been made already)