HI Mok On Fri, Apr 24, 2026 at 2:16 PM Mok <[email protected]> wrote:
> > > On Thursday, April 23rd, 2026 at 3:10 PM, David Rowley < > [email protected]> wrote: > > > On Fri, 24 Apr 2026 at 01:04, Mok <[email protected]> wrote: > > > > > > On Thursday, April 23rd, 2026 at 4:44 AM, David Rowley < > [email protected]> wrote: > > > > > > > On Thu, 23 Apr 2026 at 08:19, Mok <[email protected]> wrote: > > > > > For example, set to 0.8 a 'standard' vacuum would be triggered > when the table reached 160million with a default 200million setting. > > > > > > > > If that's what you want, why wouldn't you set the > > > > autovacuum_freeze_max_age to 160million? > > > > > > Because that would trigger a 'to-prevent-wraparound' vacuum, which is > what this change is trying to avoid. > > > > Yes, it would. Why do you want to prevent them? I believe a few people > > have been alarmed in the past about the "to prevent wraparound" text > > in pg_stat_activity or when they saw those words in the logs. The > > default 200 million autovacuum_freeze_max_age setting triggers an > > autovacuum when it's less than 10% of the way into exhausting the > > transaction space for the table. What you're proposing with an > > autovacuum_age_scale_factor of 0.1 sounds like it would result in an > > auto-vacuum when only 1% of the transaction ID space is consumed! I > > think you're under the false impression that these anti-wraparound > > vacuums are bad. They're not. > > > > There's some documentation that might be worthwhile reading in [1]. > > > > David > > > > [1] > https://www.postgresql.org/docs/18/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND > > > > > On large tables they can be quite inconvenient so avoiding them is > preferable. My example of 0.1 is to test the patch if you tried it. The > range for this > > setting is 0.1 -> 1 with the latter effectively rendering the setting > moot. > I don't know where you got that idea from. For example have a table with 1 > billion records, autovacuum_vacuum_scale_factor = 0.01 , > 50+1000000000 *0.01 = 10000050 ,you can reduce > autovacuum_vacuum_max_threshold substantially lower than 10000050 ， > vacthresh = (float4) vac_base_thresh + vac_scale_factor * reltuples; > if (vac_max_thresh >= 0 && vacthresh > (float4) vac_max_thresh) > vacthresh = (float4) vac_max_thresh; > > There's no fundamental difference between this and your parameter >
