On Tue, Mar 5, 2019 at 5:11 AM Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2019-03-04 20:03:37 +0000, Bossart, Nathan wrote: > > On 3/3/19, 9:23 PM, "Masahiko Sawada" <sawada.m...@gmail.com> wrote: > > > FWIW, I agree that we have options for vacuum as vacuum > > > command options. But for reloptions, I think if the persistence the > > > setting could be problematic we should not. According to the > > > discussions so far, I think VACUUM_SHRINK_ENABLED is the one option > > > that can be available as both vacuum command option and reloptions. > > > But I'm not sure there is good use case even if we can set > > > DISABLE_INDEX_CLEANUP as reloptions. > > > > +1 > > > > The DISABLE_INDEX_CLEANUP option is intended to help avoid transaction > > ID wraparound and should not be used as a long-term VACUUM strategy > > for a table. > > I'm not quite convinced this is right. There's plenty sites that > practically can't use autovacuum because it might decide to vacuum the > 5TB index because of 300 dead tuples in the middle of busy periods. And > without an reloption that's not controllable.
I understood the use case. I'm inclined to add DISABLE_INDEX_CLEANUP as a reloption. It's an improvement but it seems to me that the specifying a threshold or scale factor would be more useful for that case than just turning on and off. It's something like autovaucum_index_vacuum_scale_factor, 0 by default means always trigger index vacuuming and -1 means never trigger. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
