Horton

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

Laurenz Albe <laurenz.albe@cybertec.at>

View thread
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, 'Alvaro Herrera' <alvherre@2ndquadrant.com>
Cc: 'Michael Paquier' <michael@paquier.xyz>, 'Robert Haas' <robertmhaas@gmail.com>, Julien Rouhaud <rjuju123@gmail.com>, "Jamison, Kirk" <k.jamison@jp.fujitsu.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-28T08:33:02Z
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.

Tsunakawa, Takayuki wrote:
> Why do you think that it's better for VACUUM command to have the option?  I think it's a
> table property whose value is determined based on the application workload, not per VACUUM
> execution.  Rather, I think GUC is more useful to determine the behavior of the entire
> database and/or application.

I cannot speak for Alvaro, but I think that many people think that a global setting
is too dangerous (I personally don't think so).

And if we don't have a GUC, an option to VACUUM would be convenient for one-time
clean-up of a table where taking a truncation lock would be too disruptive.

> If we want to change a given execution of VACUUM, then we can ALTER TABLE SET, VACUUM,
> and ALTER TABLE SET back.

True. That ALTER TABLE would probably need a SHARE UPDATE EXCLUSIVE lock on the table,
and that's no worse than VACUUM itself.

Yours,
Laurenz Albe