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

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

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

To: Michael Paquier <michael@paquier.xyz>, 'Julien Rouhaud' <rjuju123@gmail.com>

Cc: 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-25T02:38:05Z

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 →

Add TRUNCATE parameter to VACUUM.
- b84dbc8eb80b 12.0 landed
Add vacuum_truncate reloption.
- 119dcfad988d 12.0 landed
Allow VACUUM to be run with index cleanup disabled.
- a96c41feec6b 12.0 cited

Attachments

disable-vacuum-truncation_v3.patch (application/octet-stream) patch v3

From: Michael Paquier [mailto:michael@paquier.xyz]
> I don't think that we want to use a too generic name and it seems more natural
> to reflect the context where it is used in the parameter name.
> If we were to shrink with a similar option for other contexts, we would
> most likely use a different option.  Depending on the load pattern, users
> should also be able to disable or enable a subset of contexts as well.
> 
> So I agree with Julien that [auto]vacuum_shrink_enabled is more adapted
> for this stuff.

OK, I renamed it to vacuum_shrink_enabled.


From: Julien Rouhaud [mailto:rjuju123@gmail.com]
> One last thing, I think we should at least add one regression test for
> this setting.  The one you provided previously seems perfectly suited.

Thanks, added.

Regards
Takayuki Tsunakawa