On Thu, 2003-10-16 at 16:16, Greg Stark wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Of course, this makes VACUUM run longer, and if you are waiting for it
> > to finish, it would be worse, like if you are running it at night or
> > something.
>
> My plan was that the time delay would be a parameter and pg_autovacuum would
> set it based on the observed rate at which free space is accumulating.
I don't know that pg_autovacuum is smart enough to make a good guess as
to an appropriate parameter.
> > I think the delay has to take into account the number of active
> > transactions or something.
I think this is a better plan than pg_autovacuum, this would also allow
vacuum to have a different delay for each loop depending on the current
number of transactions.
> But vacuum has no way to judge whether those transactions are really doing
> much disk i/o or only reading cached blocks, or even whether the disk i/o
> they're doing is on the same disk. They could also be waiting on the client or
> on locks from other transactions.
True, it would be a rough estimate, but at least one based on something
representative of system I/O load at that moment.