From: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Some thoughts about i/o priorities and throttling vacuum |
Date: | 2003-10-16 20:42:51 |
Message-ID: | 1066336971.10302.9.camel@zeutrh9 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2003-10-16 at 16:16, Greg Stark wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-10-16 21:34:00 | Re: Bison 1.875 for SuSE Linux 8.1? |
Previous Message | Josh Berkus | 2003-10-16 20:38:01 | Bison 1.875 for SuSE Linux 8.1? |