On Mon, Jan 16, 2023 at 10:00 AM Peter Geoghegan <p...@bowt.ie> wrote: > Now we treat the scanning and freezing strategies as two independent > choices. Of course they're not independent in any practical sense, but > I think it's slightly simpler and more elegant that way -- it makes > the GUC vacuum_freeze_strategy_threshold strictly about freezing > strategy, while still leading to VACUUM advancing relfrozenxid in a > way that makes sense. It just happens as a second order effect. Why > add a special case?
This might be a better way to explain it: The main page-level freezing commit (commit 1de58df4) already added an optimization that triggers page-level freezing "early" (early relative to vacuum_freeze_min_age). This happens whenever a page already needs to have an FPI logged inside lazy_scan_prune -- even when we're using the lazy freezing strategy. The optimization isn't configurable, and gets applied regardless of freezing strategy (technically there is no such thing as freezing strategies on HEAD just yet, though HEAD still has this optimization). There will be workloads where the FPI optimization will result in freezing many more pages -- especially when data checksums are in use (since then we could easily need to log an FPI just so pruning can set a hint bit). As a result, certain VACUUMs that use the lazy freezing strategy will freeze in almost the same way as an equivalent VACUUM using the eager freezing strategy. Such a "nominally lazy but actually quite eager" VACUUM operation should get the same benefit in terms of relfrozenxid advancement as it would if it really had used the eager freezing strategy instead. It's fairly obvious that we'll get the same benefit in relfrozenxid advancement (comparable relfrozenxid results for comparable freezing work), since the way that VACUUM decides on its scanning strategy is not conditioned on freezing strategy (whether by the ongoing VACUUM or any other VACUUM against the same table). All that matters is the conditions in the table (in particular the added cost of opting for eager scanning over lazy scanning) as indicated by the visibility map at the start of each VACUUM -- how those conditions came about really isn't interesting at that point. And so lazy_scan_strategy doesn't care about them when it chooses VACUUM's scanning strategy. There are even tables/workloads where relfrozenxid will be able to jump forward by a huge amount whenever VACUUM choosing the eager scanning strategy, despite the fact that VACUUM generally does little or no freezing to make that possible: https://wiki.postgresql.org/wiki/Freezing/skipping_strategies_patch:_motivating_examples#Patch_3 -- Peter Geoghegan
