From: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com> |
Subject: | Re: autovacuum next steps, take 2 |
Date: | 2007-02-27 17:12:22 |
Message-ID: | 45E46676.9000809@zeut.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim C. Nasby wrote:
> On Tue, Feb 27, 2007 at 12:00:41AM -0300, Alvaro Herrera wrote:
>> Jim C. Nasby wrote:
>>
>>> The advantage to keying this to autovac_naptime is that it means we
>>> don't need another GUC, but after I suggested that before I realized
>>> that's probably not the best idea. For example, I've seen clusters that
>>> are running dozens-hundreds of databases; in that environment you really
>>> need to turn naptime way down (to like a second). In that case you
>>> wouldn't want to key to naptime.
>> Actually, I've been thinking that it would be a good idea to change the
>> semantics of autovacuum_naptime so that it means the average time to
>> start a worker in any given database. That way, the time between
>> autovac runs is not dependent on the number of databases you have.
>
> BTW, another issue that I don't think we can ignore: we actually need to
> do this on a per-tablespace level, or at least have the ability to
> disable or somehow limit it. While it's not common, there are users that
> run a hundred or more databases in a single cluster; it would be ugly if
> we suddenly had 100 vacuums trying to run on the same set of drives
> concurrently.
I think we all agree that autovacuum needs to become tablespace aware at
some point, but I think that is further down the line, we're having
enough trouble figuring things out without that additional complication.
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2007-02-27 17:15:52 | Re: Resumable vacuum proposal and design overview |
Previous Message | Kris Jurka | 2007-02-27 17:11:59 | Re: 7.x horology regression test on Solaris buildfarm machines |