On Wed, Jun 20, 2018 at 12:00 PM Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > On Wed, Jun 20, 2018 at 8:32 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Wed, Jun 20, 2018 at 1:00 AM, Alexander Korotkov > > > Ok. I've rephrased comment a bit. Also, you created "index vacuum" > > > subsection in the "resource usage" section. I think it's not > > > appropriate for this option to be in "resource usage". Ideally it > > > should be grouped with other vacuum options, but we don't have single > > > section for that. "Autovacuum" section is also not appropriate, > > > because this guc works not only for autovacuum. So, most semantically > > > close options, which affects vacuum in general, are > > > vacuum_freeze_min_age, vacuum_freeze_table_age, > > > vacuum_multixact_freeze_min_age and vacuum_multixact_freeze_table_age, > > > which are located in "client connection defaults" section. So, I > > > decided to move this GUC into this section. I also change the section > > > in GUC definition (guc.c) from AUTOVACUUM to CLIENT_CONN_STATEMENT. > > > > Agreed. So should we move it to 19.11 Client Connection Defaults in > > doc as well? And I think it's better if this option places next to > > other vacuum options for finding easier. Attached patch changes them > > so. Please review it. > > Right, thank you. Looks good for me. > I'm going to commit this if no objections.
Pushed. Regarding maximum value for vacuum_cleanup_index_scale_factor. I think introducing special value with "never cleanup" meaning would be overkill for post feature freeze enhancement. So, I propose to just increase maximum value for both GUC and reloption. See the attached patch. It also changes calculations _bt_vacuum_needs_cleanup() for better handling of large values (just some kind of overflow paranoia). ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
vacuum_cleanup_index_scale_factor-max-2.patch
Description: Binary data