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

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'Michael Paquier' <michael(at)paquier(dot)xyz>
Cc: 'Robert Haas' <robertmhaas(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, 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-28 03:41:03
Message-ID: 0A3221C70F24FB45833433255569204D1FBBA69A@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: Michael Paquier [mailto:michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-28 03:41:20 Re: Why don't we have a small reserved OID range for patch revisions?
Previous Message Michael Paquier 2019-02-28 03:25:27 Re: psql display of foreign keys