Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Adrien Mobile <adrien.nayrat@anayrat.info>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, Fujii Masao <masao.fujii@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-05T19:30:20Z
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 Fri, Apr 5, 2019 at 3:28 PM Adrien Mobile <adrien.nayrat@anayrat.info> wrote:
> How about TRIM?

The problem, in my view, is not that there is anything ipso facto
wrong with SHRINK.  The problem is that it's a turn term that has only
de minimis use up until now.  Replacing it with some other term that
has never before been used to refer to the behavior under discussion
does not, in my view, fix anything.

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