Re: RFC: changing autovacuum_naptime semantics

On Mar 7, 2007, at 4:00 PM, Alvaro Herrera wrote:
> Is everybody OK with putting per-database worker limits on a  
> pg_database
> column?

I'm worried that we would live to regret such a limit. I can't really  
see any reason to limit how many vacuums are occurring in a database,  
because there's no limiting factor there; you're either going to be  
IO bound (per-tablespace), or *maybe* CPU-bound (perhaps the  
Greenplum folks could enlighten us as to whether they run into vacuum  
being CPU-bound on thumpers).

Changing the naptime behavior to be database related makes perfect  
sense, because the minimum XID you have to worry about is a per- 
database thing; I just don't see limiting the number of vacuums as  
being per-database, though. I'm also skeptical that we'll be able to  
come up with a good way to limit the number of backends until we get  
the hot table issue addressed. Perhaps a decent compromise for now  
would be to limit how many 'small table' vacuums could run on each  
tablespace, and then limit how many 'unlimited table size' vacuums  
could run on each tablespace, where 'small table' would probably have  
to be configurable. I don't think it's the best final solution, but  
it should at least solve the immediate need.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)