Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: 'Julien Rouhaud' <rjuju123@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-22T04:47:52Z
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 Fri, Feb 22, 2019 at 02:38:56AM +0000, Tsunakawa, Takayuki wrote: > From: Julien Rouhaud [mailto:rjuju123@gmail.com] >> FWIW, I prefer shrink over truncate, though I'd rather go with >> vacuum_shink_enabled as suggested previously. > > Thanks. I'd like to leave a committer to choose the name. FWIW, I > chose shrink_enabled rather than vacuum_shrink_enabled because this > property may be used in other shrink situations in the future. What > I imagined was that with the zheap, DELETE or some maintenance > operation, not vacuum, may try to shrink the table. I meant this > property to indicate "whether this table shrinks or not" regardless > of the specific operation that can shrink the table. I don't think that we want to use a too generic name and it seems more natural to reflect the context where it is used in the parameter name. If we were to shrink with a similar option for other contexts, we would most likely use a different option. Depending on the load pattern, users should also be able to disable or enable a subset of contexts as well. So I agree with Julien that [auto]vacuum_shrink_enabled is more adapted for this stuff. -- Michael