From: Michael Paquier [mailto:mich...@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_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
