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 по дате отправления: