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 | 0A3221C70F24FB45833433255569204D1FB9F614@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: reloption to prevent VACUUM from truncating empty pages at theend of relation (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Re: reloption to prevent VACUUM from truncating empty pages at theend of relation |
Список | pgsql-hackers |
From: Julien Rouhaud [mailto:rjuju123@gmail.com] > FWIW, I prefer shrink over truncate, though I'd rather go with > vacuum_shink_enabled as suggested previously. Thanks. I'd like to leave a committer to choose the name. FWIW, I chose shrink_enabled rather than vacuum_shrink_enabledbecause this property may be used in other shrink situations in the future. What I imagined was thatwith the zheap, DELETE or some maintenance operation, not vacuum, may try to shrink the table. I meant this propertyto indicate "whether this table shrinks or not" regardless of the specific operation that can shrink the table. > I'm not sure that I get this comment. Since both require a > ShareUpdateExclusiveLock, you can't change the parameter while a > VACUUM is active on that table. Did you wanted to use another lock > mode? No, changing the parameter acquires ShareUpdaeExclusive lock. I just imitated the description for n_distinct in the samecomment block. The meaning is that the setting cannot be changed during VACUUM, so in-flight VACUUM is not affected. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: