| From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, jd(at)commandprompt(dot)com, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: temporarily stop autovacuum |
| Date: | 2009-02-12 10:04:37 |
| Message-ID: | 0CBDFB72109208B183692428@teje |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
--On Mittwoch, Februar 11, 2009 13:18:11 -0500 Robert Haas
<robertmhaas(at)gmail(dot)com> wrote:
> In any case it's not difficult to write a script that loops over all
> of your tables with ALTER TABLE. It's probably not as fast as a
> single UPDATE statement, but I suspect you'd need to have an enormous
> number of tables for that to matter much.
Agreed, we often recommend this for all kinds of GRANTs, REVOKEs and so on.
But while we don't have (yet) any facility to achieve this behavior with
these commands, for autovacuum, a possible solution exists, and although a
crude temporarily one, i know people seeing pg_autovacuum as a feature to
do exactly this kind of maintenance.
--
Thanks
Bernd
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matteo Beccati | 2009-02-12 12:05:24 | Re: DISCARD ALL failing to acquire locks on pg_listen |
| Previous Message | Heikki Linnakangas | 2009-02-12 07:50:04 | Hot Standby: subxid cache changes |