Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
От | Julien Rouhaud |
---|---|
Тема | Re: reloption to prevent VACUUM from truncating empty pages at theend of relation |
Дата | |
Msg-id | CAOBaU_aTq7ZGXvd7oihRj_oPb81CSmUX5Wpjt4NqprkJPFQpew@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: reloption to prevent VACUUM from truncating empty pages at theend of relation ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
|
Список | pgsql-hackers |
Hi, On Mon, Feb 4, 2019 at 1:25 AM Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: > > FYI, it seems that the user sees "shrink" rather than "truncate" in the documentation as below, although these are aboutVACUUM FULL. > > https://www.postgresql.org/docs/devel/sql-vacuum.html > would like the table to physically shrink to occupy less disk space > > https://www.postgresql.org/docs/devel/routine-vacuuming.html > shrink a table back to its minimum size and return the disk space to the operating system, > > > > Anyway, I don't have any favor about naming this, and I hope native English speakers will choose the best name. I won'tobject to whatever name any committer chooses. FWIW, I prefer shrink over truncate, though I'd rather go with vacuum_shink_enabled as suggested previously. The patch still applies cleanly and works as intended. About: + * shrink_enabled can be set at ShareUpdateExclusiveLock because it + * is only used during VACUUM, which uses a ShareUpdateExclusiveLock, + * so the VACUUM will not be affected by in-flight changes. Changing its + * value has no affect until the next VACUUM, so no need for stronger lock. 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?
В списке pgsql-hackers по дате отправления: