Horton

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

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

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

From: Alvaro Herrera [mailto:alvherre@2ndquadrant.com]
> Robert used the phrase "attractive nuisance", which maybe sounds like a
> good thing to have to a non native speaker, but it actually isn't -- he
> was saying we should avoid a GUC at all, and I can see the reason for
> that.  I think we should have a VACUUM option and a reloption, but no
> GUC.

Uh, thanks.  I've just recognized I didn't know the meaning of "nuisance."  I've looked up the meaning in the dictionary.  Nuisance is like a trouble maker...

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.

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


Regards
Takayuki Tsunakawa