On Fri, 2002-11-29 at 06:59, Matthew T. O'Connor wrote:
> On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
> > On 28 Nov 2002 at 10:45, Tom Lane wrote:
> > > "Matthew T. O'Connor" <matthew@zeut.net> writes:
> > > > interesting thought. I think this boils down to how many knobs do we
> > > > need to put on this system. It might make sense to say allow upto X
> > > > concurrent vacuums, a 4 processor system might handle 4 concurrent
> > > > vacuums very well.
> > >
> > > This is almost certainly a bad idea. vacuum is not very
> > > processor-intensive, but it is disk-intensive. Multiple vacuums running
> > > at once will suck more disk bandwidth than is appropriate for a
> > > "background" operation, no matter how sexy your CPU is. I can't see
> > > any reason to allow more than one auto-scheduled vacuum at a time.
> >
> > Hmm.. We would need to take care of that as well..
>
> 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?
Greg