On Fri, Mar 3, 2023 at 2:43 AM Simon Elbaz <elbazsimon9@gmail.com> wrote:
> I expected it not to be processed by vacuum freeze.
> However it has been entirely frozen.
> Moreover, among the 51 rows, only 1 was eligible for freeze because its XID was older than vacuum_freeze_min_age.
The effect that you noticed is a consequence of page-level freezing,
which is new to Postgres 16. VACUUM will now freeze all of the tuples
on a page whenever it needs to freeze any tuples at all (barring any
tuples that are fundamentally ineligible due to being after the
removable/freezable cutoff). This is justified by the cost profile.
Once we decide to freeze at least one tuple of a page, the added cost
in WAL is low enough that it really doesn't make sense to not just
freeze everything.
The page that gets frozen by your test case is also set all-frozen in
the visibility map. Without the optimization, we'd have frozen that
one tuple and then set the page all-visible. The page would likely be
frozen again by the next aggressive VACUUM, which is usually much more
expensive.
--
Peter Geoghegan
