From: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
---|---|
To: | Rod Taylor <rbt(at)rbt(dot)ca> |
Cc: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, shridhar_daithankar(at)persistent(dot)co(dot)in, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Auto Vacuum Daemon (again...) |
Date: | 2002-12-10 17:00:13 |
Message-ID: | 1039539613.4593.10.camel@mouse.copelandconsulting.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2002-12-10 at 08:42, Rod Taylor wrote:
> > > Not sure what you mean by that, but it sounds like the behaviour of my AVD
> > > (having it block until the vacuum command completes) is fine, and perhaps
> > > preferrable.
> >
> > I can easily imagine larger systems with multiple CPUs and multiple disk
> > and card bundles to support multiple databases. In this case, I have a
> > hard time figuring out why you'd not want to allow multiple concurrent
> > vacuums. I guess I can understand a recommendation of only allowing a
> > single vacuum, however, should it be mandated that AVD will ONLY be able
> > to perform a single vacuum at a time?
>
> Hmm.. CPU time (from what I've seen) isn't an issue. Strictly disk. The
> big problem with multiple vacuums is determining which tables are in
> common areas.
>
> Perhaps a more appropriate rule would be 1 AVD per tablespace? Since
> PostgreSQL only has a single tablespace at the moment....
But tablespace is planned for 7.4 right? Since tablespace is supposed
to go in for 7.4, I think you've hit the nail on the head. One AVD per
tablespace sounds just right to me.
--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2002-12-10 17:05:42 | Re: psql's \d commands --- end of the line for |
Previous Message | Greg Copeland | 2002-12-10 16:56:32 | Re: 7.4 Wishlist |