From: Michael Paquier [mailto:michael@paquier.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_shrinkor something like that, but enable_xxx seems to be used solely for planner control. Plus,
vacuum-relatedparameters 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
takeseffect.
* 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
againto 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
