RE: Re: reloption to prevent VACUUM from truncating empty pages atthe end of relation
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Re: reloption to prevent VACUUM from truncating empty pages atthe end of relation |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FBEFCEE@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: Re: reloption to prevent VACUUM from truncating empty pages atthe end of relation (Julien Rouhaud <rjuju123@gmail.com>) |
Список | pgsql-hackers |
From: Masahiko Sawada [mailto:sawada.mshk@gmail.com] > "VACUUM" needs <command> or "vacuum" is more appropriate here? Looking at the same file and some other files, "vacuum" looks appropriate because it represents the vacuum action, not thespecific VACUUM command. > The format of the documentation of new option is a bit weird. Could it > be possible to adjust it around 80 characters per line like other > description? Ah, fixed. It's easy to overlook the style with the screen reader software... I've been wondering if there are good settingsfor editing .sgml in Emacs that, for example, puts appropriate number of spaces at the beginning of each line when<Tab> is pressed, automatically break the long line and put spaces, etc. From: Julien Rouhaud [mailto:rjuju123@gmail.com] > also, the documentation should point out that freeing is not > guaranteed. Something like > > + The default is true. If true, VACUUM will try to free empty > pages at the end of the table. That's nice. Done. > > I'm not sure the consensus we got here but we don't make the vacuum > > command option for this? > > I don't think here's a clear consensus, but my personal vote is to add > it, with SHRINK_TABLE = [ force_on | force_off | default ] (unless a > better proposal has been made already) IMO, which I mentioned earlier, I don't think the VACUUM option is necessary because: (1) this is a table property which is determined based on the expected workload, not the one that people want to change perVACUUM operation (2) if someone wants to change the behavior for a particular VACUUM operation, he can do it using ALTER TABLE SET. Anyway, we can add the VACUUM option separately if we want it by all means. I don't it to be the blocker for this featureto be included in PG 12, because the vacuum truncaton has been bothering us like others said in this and other threads... Regards Takayuki Tsunakawa
Вложения
В списке pgsql-hackers по дате отправления: