Re: Trigger more frequent autovacuums of heavy insert tables
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Peter Geoghegan <pg@bowt.ie>, David Rowley <dgrowley@gmail.com>
Date: 2025-02-19T21:59:54Z
Lists: pgsql-hackers
On Wed, Feb 19, 2025 at 04:36:05PM -0500, Melanie Plageman wrote: > This makes me think I should also not cap relallfrozen when using it > in relation_needs_vacanalyze(). There I cap it to relallvisible and > relallvisible is capped to relpages. One of the ideas behind letting > people modify these stats in pg_class is that they can change a single > field to see what the effect on their system is, right? Right. Capping these values to reflect reality seems like it could make that more difficult. >> Should we allow manipulating relallfrozen like we do relallvisible? My >> assumption is that would even be required for the ongoing statistics >> import/export work. > > Why would it be required for the statistics import/export work? It's probably not strictly required, but my naive expectation would be that we'd handle relallfrozen just like relallvisible, which appears to be dumped in the latest stats import/export patch. Is there any reason we shouldn't do the same for relallfrozen? -- nathan
Commits
-
doc: Update formula for vacuum insert threshold.
- cbdce71b9984 19 (unreleased) landed
- c99436f43322 18.2 landed
-
Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.
- 3d351d916b20 14.0 cited
-
Measure the number of all-visible pages for use in index-only scan costing.
- e6858e665731 9.2.0 cited