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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
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 02:24:22
Message-ID: 20190228022422.GH1617@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 28, 2019 at 01:05:07AM +0000, Tsunakawa, Takayuki wrote:
> From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
>> I don't think that a VACUUM option would be out of place, but a GUC
>> sounds like an attractive nuisance to me. It will encourage people to
>> just flip it blindly instead of considering the particular cases where
>> they need that behavior, and I think chances are good that most people
>> who do that will end up being sad.

I won't disagree with you on that. I hear enough about people
disappointed that VACUUM does not clean up their garbage enough and
that tables are bloated.. And making autovacuum too aggressive is no
good either.

> Ouch, I sent my previous mail before reading this. I can understand
> it may be cumbersome to identify and specify each table, so I tend
> to agree the parameter in postgresql, which is USERSET to allow
> ALTER DATABASE/USER SET to tune specific databases and applications.
> But should the vacuuming of system catalogs also follow this
> setting?

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 priority to the command-level option.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-28 02:26:15 Re: Allowing extensions to supply operator-/function-specific info
Previous Message Amit Langote 2019-02-28 02:21:59 Re: pg_partition_tree crashes for a non-defined relation