Re: Auto Vacuum Daemon (again...)
От | Greg Copeland |
---|---|
Тема | Re: Auto Vacuum Daemon (again...) |
Дата | |
Msg-id | 1039476305.21029.5.camel@mouse.copelandconsulting.net обсуждение исходный текст |
Ответ на | Re: Auto Vacuum Daemon (again...) ("Matthew T. O'Connor" <matthew@zeut.net>) |
Ответы |
Re: Auto Vacuum Daemon (again...)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: