On Wed, Jan 25, 2023 at 6:33 PM Andres Freund <and...@anarazel.de> wrote: > My point was the other way round. That vacuum_freeze_min_age *prevented* us > from freezing rows "too soon" - obviously a very blunt instrument.
Yes, not freezing at all until aggressive vacuum is definitely good when you don't really need to freeze at all. > Since page level freezing, it only partially does that, because we'll freeze > even newer rows, if pruning triggered an FPI (I don't think that's quite the > right check, but that's a separate discussion). But the added cost is very low, and it might well make all the difference. > As far as I can tell, with the eager strategy, the only thing > vacuum_freeze_min_age really influences is whether we'll block waiting for a > cleanup lock. IOW, VACUUM on a table > vacuum_freeze_strategy_threshold is > now a slightly less-blocking version of VACUUM FREEZE. That's simply not true, at all. I'm very surprised that you think that. The commit message very clearly addresses this. You know, the part that you specifically quoted to complain about today! Once again I'll refer you to my Wiki page on this: https://wiki.postgresql.org/wiki/Freezing/skipping_strategies_patch:_motivating_examples#Patch_2 The difference between this and VACUUM FREEZE is described here: "Note how we freeze most pages, but still leave a significant number unfrozen each time, despite using an eager approach to freezing (2981204 scanned - 2355230 frozen = 625974 pages scanned but left unfrozen). Again, this is because we don't freeze pages unless they're already eligible to be set all-visible. We saw the same effect with the first pgbench_history example, but it was hardly noticeable at all there. Whereas here we see that even eager freezing opts to hold off on freezing relatively many individual heap pages, due to the observed conditions on those particular heap pages." If it was true that eager freezing strategy behaved just the same as VACUUM FREEZE (at least as far as freezing is concerned) then scenarios like this one would show that VACUUM froze practically all of the pages it scanned -- maybe fully 100% of all scanned pages would be frozen. This effect is absent from small tables, and I suspect that it's absent from your test case in part because you used a table that was too small. Obviously the way that eager freezing strategy avoids freezing concurrently modified pages isn't perfect. It's one approach to limiting the downside from eager freezing, in tables (or even individual pages) where it's inappropriate. Of course that isn't perfect, but it's a significant factor. -- Peter Geoghegan