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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)