On Fri, 27 Mar 2020 at 07:51, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2020-03-26 10:12:39 +0100, Laurenz Albe wrote: > > On Wed, 2020-03-25 at 23:19 +0300, Alexander Korotkov wrote: > > I am reluctant to introduce new semantics like a reloption value of -2 > > to disable a feature in this patch right before feature freeze. > > > > I believe there are enough options to disable insert-only vacuuming for > > an individual table: > > > - Set the threshold to 2147483647. True, that will not work for very > > large tables, but I think that there are few tables that insert that > > many rows before they hit autovacuum_freeze_max_age anyway. > > > > - Set the scale factor to some astronomical value. > > Meh. You *are* adding new semantics with these. And they're terrible.
I've modified this to allow a proper way to disable the entire feature by allowing the setting to be set to -1 to disable the feature. I feel people are fairly used to using -1 to disable various features (e.g. log_autovacuum_min_duration). I've used the special value of -2 for the reloption to have that cascade to using the GUC instead. The autovacuum_vacuum_insert_threshold reloption may be explicitly set to -1 to disable autovacuums for inserts for the relation. I've also knocked the default threshold down to 1000. I feel this is a better value given that the scale factor is now 0.2. There seemed to be no need to exclude smaller tables from seeing gains such as index-only scans. If nobody objects, I plan to push this one shortly. David
insert_autovac_v12.patch
Description: Binary data