Re: Eagerly scan all-visible pages to amortize aggressive vacuum
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Robert Treat <rob@xzilla.net>
Cc: Melanie Plageman <melanieplageman@gmail.com>,
Marcos Pegoraro <marcos@f10.com.br>, Alena Rybakina <a.rybakina@postgrespro.ru>,
Andres Freund <andres@anarazel.de>, Nazir Bilal Yavuz <byavuz81@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>, Peter Geoghegan <pg@bowt.ie>
Date: 2025-01-27T17:03:53Z
Lists: pgsql-hackers
On Sun, Jan 26, 2025 at 3:11 PM Robert Treat <rob@xzilla.net> wrote: > Hmm... isn't "don't try" really more logically equivalent to "stop > after zero failures", with "try until zero failures" more of the > inverse... more like "never stop never stopping"? No. Or at least, I don't think that's how English works. > So that middle bit is trying to act as glue that pulls this all > together. I thought the previous version was closer, with Haas's > feedback I might go with something more like this: > > <para> > - <command>VACUUM</command> normally only scans pages that have been modified > - since the last vacuum, but > <structfield>relfrozenxid</structfield> can only be > - advanced when every page of the table > - that might contain unfrozen XIDs is scanned. This happens when > + While <command>VACUUM</command> typically scans pages that have been > + modified since the last vacuum, it may also eagerly scan some > all-visible but not > + all-frozen pages in an attempt to freeze them, but the > + <structfield>relfrozenxid</structfield> will only be advanced when > + every page of the table that might contain unfrozen XIDs is scanned. > + This happens when I like that. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
pg_stat_statements: Add counters for generic and custom plans
- 3357471cf9f5 19 (unreleased) cited
-
Remove leftover mentions of XLOG_HEAP2_FREEZE_PAGE records
- b7493e1ab353 18.0 landed
-
Rename LVRelState->frozen_pages
- f020baa0662c 18.0 landed