On Thu, Feb 28, 2019 at 01:05:07AM +0000, Tsunakawa, Takayuki wrote:
> From: Robert Haas [mailto:robertmhaas@gmail.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