On 10 Dec 2002, 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 Postgresql can already place different databases on different data
stores. I.e. initlocation and all. If someone was using multiple SCSI
cards with multiple JBOD or RAID boxes hanging off of a box, they would
have the same thing, effectively, that you are talking about.
So, someone out there may well be able to use a multiple process AVD right
now. Imagine m databases on n different drive sets for large production
databases.
