Horton

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

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.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-25T09:25:07Z
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 Mon, Feb 25, 2019 at 08:47:28AM +0100, Julien Rouhaud wrote:
> Ah good point.  We could also use something like
> pg_relation_size('reloptions_test') /
> current_setting('block_size')::bigint but >0 should be enough for this
> test.

Also, shouldn't the relopt check happen in
should_attempt_truncation()?  It seems to me that if we use this
routine somewhere else then it should be controlled by the option.

At the same time, we also have REL_TRUNCATE_FRACTION and
REL_TRUNCATE_MINIMUM which could be made equally user-tunnable.
That's more difficult to control, still why don't we also consider
this part?

Another thing that seems worth thinking about is a system-level GUC,
and an option in the VACUUM command to control if truncation should
happen or not.  We have a lot of infrastructure to control such
options between vacuum and autovacuum, so it could be a waste to not
consider potential synergies.
--
Michael