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

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Date: 2019-02-21 16:32:17
Message-ID: CAOBaU_aTq7ZGXvd7oihRj_oPb81CSmUX5Wpjt4NqprkJPFQpew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Feb 4, 2019 at 1:25 AM Tsunakawa, Takayuki
<tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
>
> FYI, it seems that the user sees "shrink" rather than "truncate" in the documentation as below, although these are about VACUUM FULL.
>
> https://www.postgresql.org/docs/devel/sql-vacuum.html
> would like the table to physically shrink to occupy less disk space
>
> https://www.postgresql.org/docs/devel/routine-vacuuming.html
> shrink a table back to its minimum size and return the disk space to the operating system,
>
>
>
> Anyway, I don't have any favor about naming this, and I hope native English speakers will choose the best name. I won't object to whatever name any committer chooses.

FWIW, I prefer shrink over truncate, though I'd rather go with
vacuum_shink_enabled as suggested previously.

The patch still applies cleanly and works as intended. About:

+ * shrink_enabled can be set at ShareUpdateExclusiveLock because it
+ * is only used during VACUUM, which uses a ShareUpdateExclusiveLock,
+ * so the VACUUM will not be affected by in-flight changes. Changing its
+ * value has no affect until the next VACUUM, so no need for stronger lock.

I'm not sure that I get this comment. Since both require a
ShareUpdateExclusiveLock, you can't change the parameter while a
VACUUM is active on that table. Did you wanted to use another lock
mode?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-02-21 16:33:16 Re: Delay locking partitions during INSERT and UPDATE
Previous Message Pavel Stehule 2019-02-21 16:31:01 Re: proposal: variadic argument support for least, greatest function