On Thu, Apr 4, 2019 at 1:26 PM Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com> wrote: > > From: Fujii Masao [mailto:masao.fu...@gmail.com] > > reloption for TOAST is also required? > > # I've come back to the office earlier than planned... > > Hm, there's no reason to not provide toast.vacuum_shrink_enabled. Done with > the attached patch. >
Thank you for updating the patch! + <term><literal>vacuum_shrink_enabled</literal>, <literal>toast.vacuum_shrink_enabled</literal> (<type>boolean</type>)</term> + <listitem> + <para> + Enables or disables shrinking the table when it's vacuumed. + This also applies to autovacuum. + The default is true. If true, VACUUM frees empty pages at the end of the table. "VACUUM" needs <command> or "vacuum" is more appropriate here? + Shrinking the table requires <literal>ACCESS EXCLUSIVE</literal> lock on the table. + It can take non-negligible time when the shared buffer is large. Besides, <literal>ACCESS EXCLUSIVE</literal> + lock could lead to query cancellation on the standby server. + If the workload is likely to reuse the freed space soon + (e.g., UPDATE-heavy, or new rows will be added after deleting + old rows), setting this parameter to false makes sense to avoid unnecessary shrinking. + </para> + </listitem> + </varlistentry> 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? I'm not sure the consensus we got here but we don't make the vacuum command option for this? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
