Re: [HACKERS] More detail on settings for pgavd?

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