Matthew,
> Actually, this might be a necessary addition as pg_autovacuum currently
> suffers from the startup transients that the FSM used to suffer from,
> that is, it doesn't remember anything that happened the last time it
> ran. A pg_autovacuum database could also be used to store thresholds
> and counts from the last time it ran.
I don't see how a seperate database is better than a table in the databases.,
except that it means scanning only one table and not one per database. For
one thing, making it a seperate database could make it hard to back up and
move your database+pg_avd config.
But I don't feel strongly about it.
> Where are you getting 13% from?
13% * 3/4 ~~ 10%
And I think both of use agree that vacuuming tables with less than 10% changes
is excessive and could lead to problems on its own, like overlapping vacuums.
> Do you know of an easy way to get a
> count of the total pages used by a whole cluster?
Select sum(relpages) from pg_class.
> I do like the concept though as long as we find good values for
> min_fsm_percentage and min_autovac_scaling_factor.
See above. I propose 0.13 and 0.1
> Which we already keep a copy of inside of pg_autovacuum, and update
> after we issue a vacuum.
Even easier then.
BTW, do we have any provisions to avoid overlapping vacuums? That is, to
prevent a second vacuum on a table if an earlier one is still running?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
