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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.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>, Fujii Masao <masao.fujii@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-03-26T17:30:13Z
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 Tue, Mar 26, 2019 at 11:23 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > I don't see a patch with the naming updated, here or there, and I'm
> > going to be really unhappy if we end up with inconsistent naming
> > between two patches that do such fundamentally similar things.  -1
> > from me to committing either one until that inconsistency is resolved.
>
> Agreed. I've just submitted the latest version patch that adds
> INDEX_CLEANUP option and vacuum_index_cleanup reloption. I already
> mentioned on that thread but I agreed with adding phrase positively
> than negatively. So if we got consensus on such naming the new options
> added by this patch could be something like SHRINK option (with
> true/false) and vacuum_shrink reloption.

No, that's just perpetuating the problem.  Then you have an option
SHRINK here that you set to TRUE to skip something, and an option
INDEX_CLEANUP over there that you set to FALSE to skip something.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company