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: 'Michael Paquier' <michael@paquier.xyz>
Cc: 'Robert Haas' <robertmhaas@gmail.com>, 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-28T03:41:03Z
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: Michael Paquier [mailto:michael@paquier.xyz]
> So we could you consider adding an option for the VACUUM command as well
> as vacuumdb?  The interactions with the current patch is that you need to
> define the behavior at the beginning of vacuum for a given heap, instead
> of reading the parameter at the time the truncation happens, and give

I'm not confident whether this is the same as the above, I imagined this:

* Add a new USERSET GUC vacuum_shrink_table = {on | off}, on by default.
This follows the naming style "verb_object" like log_connections and enable_xxx.  We may want to use enable_vacuum_shrink or something like that, but enable_xxx seems to be used solely for planner control.  Plus, vacuum-related parameters seem to start with vacuum_.

* Give priority to the reloption, because it's targeted at a particular table.  If the reloption is not set, the GUC takes effect.

* As a consequence, the user can change the behavior of VACUUM command by SETting the GUC in the same session in advance, when the reloption is not set.  If the reloption is set, the user can ALTER TABLE SET, VACUUM, and ALTER TABLE again to restore the table's setting.  But I don't think this use case (change whether to shrink per VACUUM command execution) is necessary.  This is no more than simply possible.


Regards
Takayuki Tsunakawa