Re: new GUC var: autovacuum_process_all_tables
От | Simon Riggs |
---|---|
Тема | Re: new GUC var: autovacuum_process_all_tables |
Дата | |
Msg-id | 1233878250.4500.621.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: new GUC var: autovacuum_process_all_tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: new GUC var: autovacuum_process_all_tables
Re: new GUC var: autovacuum_process_all_tables |
Список | pgsql-hackers |
On Thu, 2009-02-05 at 17:08 -0500, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Thu, 2009-02-05 at 16:29 -0500, Tom Lane wrote: > >> It'd make more sense to put the effort into developing > >> better scheduling control over autovacuum, such as a concept of > >> maintenance windows. > > > We need that as well, not instead of. > > I disagree; adding every frammish anyone could ever think of is not > an overall improvement to the system. I like your word frammish and am watchful of such things myself. > My feeling is that we should be trying to eliminate use-cases for > cron-driven vacuuming, Agreed. > not trying to make sure that cron-driven > scripts can do anything autovacuum can. I'm not in favour of limiting our capability to internal actions only. If we add a capability for scheduling work, we can easily make it capable of scheduling many kinds of work. Writing an application maintenance utility in PL/pgSQL is much better than having to write it for all the different servers an application may need to run on. We can't ignore that many people use Windows. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: