RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: reloption to prevent VACUUM from truncating empty pages at theend of relation |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FBBA69A@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: reloption to prevent VACUUM from truncating empty pages at theend of relation (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: