On Wed, Jan 25, 2023 at 5:15 PM Andres Freund <and...@anarazel.de> wrote: > However, it significantly increases the overall work when rows have a somewhat > limited lifetime. The documented reason why vacuum_freeze_min_age exist - > although I think it doesn't really achieve its documented goal anymore, after > the recent changes page-level freezing changes.
Huh? vacuum_freeze_min_age hasn't done that, at all. At least not since the visibility map went in back in 8.4: https://wiki.postgresql.org/wiki/Freezing/skipping_strategies_patch:_motivating_examples#Today.2C_on_Postgres_HEAD_2 That's why we literally do ~100% of all freezing in aggressive mode VACUUM with append-only or append-mostly tables. > > VACUUM determines its freezing strategy based on the value of the new > > vacuum_freeze_strategy_threshold GUC (or reloption) with logged tables; > > tables that exceed the size threshold use the eager freezing strategy. > > I think that's not a sufficient guard at all. The size of a table doesn't say > much about how a table is used. Sufficient for what purpose? > > Eager freezing is strictly more aggressive than lazy freezing. Settings > > like vacuum_freeze_min_age still get applied in just the same way in > > every VACUUM, independent of the strategy in use. The only mechanical > > difference between eager and lazy freezing strategies is that only the > > former applies its own additional criteria to trigger freezing pages. > > That's only true because vacuum_freeze_min_age being has been fairly radically > redefined recently. So? This part of the commit message is a simple statement of fact. -- Peter Geoghegan
