On Tue, Mar 17, 2020 at 08:42:07PM +0100, Laurenz Albe wrote: > Also, since aggressive^H^H^H^H^H^H^H^H^H^Hproactive freezing seems to be a > performance problem in some cases (pages with UPDATEs and DELETEs in otherwise > INSERT-mostly tables), I have done away with the whole freezing thing, > which made the whole patch much smaller and simpler. > > Now all that is introduced are the threshold and scale factor and > the new statistics counter to track the number of inserts since the last > VACUUM. > > Updated patch attached. > > Perhaps we can reach a consensus on this reduced functionality.
+1 I still suggest scale_factor maximum of 1e10, like 4d54543efa5eb074ead4d0fadb2af4161c943044 Which alows more effectively disabling it than a factor of 100, which would progress like: ~1, 1e2, 1e4, 1e6, 1e8, 1e10, .. I don't think that 1e4 would be a problem, but 1e6 and 1e8 could be. With 1e10, it's first vacuumed when there's 10billion inserts, if we didn't previous hit the n_dead threshold. I think that's ok? If one wanted to disable it up to 1e11 tuples, I think they'd disable autovacuum, or preferably just implement an vacuum job. The commit message says: |The scale factor defaults to 0, which means that it is |effectively disabled, but it offers some flexibility ..but "it" is ambiguous, so should say something like: "the table size does not contribute to the autovacuum threshold". -- Justin
