Re: Auto Vacuum Daemon (again...)
От | scott.marlowe |
---|---|
Тема | Re: Auto Vacuum Daemon (again...) |
Дата | |
Msg-id | Pine.LNX.4.33.0212101207360.3611-100000@css120.ihs.com обсуждение исходный текст |
Ответ на | Re: Auto Vacuum Daemon (again...) (Rod Taylor <rbt@rbt.ca>) |
Ответы |
Re: Auto Vacuum Daemon (again...)
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: