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