Re: Autovacuum loose ends

From: Hannu Krosing
Subject: Re: Autovacuum loose ends
Date: ,
Msg-id: 1121369580.4897.14.camel@fuji.krosing.net
(view: Whole thread, Raw)
In response to: Re: Autovacuum loose ends  (Tom Lane)
List: pgsql-hackers

Tree view

Autovacuum loose ends  (Tom Lane, )
 Re: Autovacuum loose ends  ("Matthew T. O'Connor", )
  Re: Autovacuum loose ends  (Tom Lane, )
   Re: Autovacuum loose ends  ("Matthew T. O'Connor", )
   Re: Autovacuum loose ends  (Greg Stark, )
   Re: Autovacuum loose ends  (Hannu Krosing, )
   Re: Autovacuum loose ends  (Ron Mayer, )
    Re: Autovacuum loose ends  (Tom Lane, )
 Re: Autovacuum loose ends  (Alvaro Herrera <-ip.org>, )
  Re: Autovacuum loose ends  (Tom Lane, )
  Re: Autovacuum loose ends  (Tom Lane, )
 Re: Autovacuum loose ends  (Alvaro Herrera <-ip.org>, )
  Re: Autovacuum loose ends  (Tom Lane, )
   Re: Autovacuum loose ends  (Alvaro Herrera <-ip.org>, )

On N, 2005-07-14 at 14:12 -0400, Tom Lane wrote:
> "Matthew T. O'Connor" <> writes:
> > Speaking of which, I think I mentioned this to Alvaro, but I guess it 
> > just didn't make it in.  The pg_autovacuum table should have a few 
> > additional columns that allow setting vacuum delay settings on a per 
> > table basis.  I also think that there should be GUC settings for the 
> > default autovacuum delay settings which an admin might want to be 
> > separate from the system wide default vacuum delay settings.
> 
> I was thinking GUC settings only; is there a real use-case for
> table-specific delay parameters? 

Probably not, unless we also have table-specific load and/or
maintenance-window thresholds above which they are not vacuumed.

Often there are some tables that need to be vacuumed constantly even at
the highest loads (usually small but fast-changing) and some that need
to be vacuumed only at lower activity periods (usually big and changing
at a lower rate).

> ISTM the point of the delay parameters
> for autovac is to put a lid on its impact on interactive response.  Seen
> in that light, you do not care exactly which table it's hitting at the
> moment.

The only difference I can see is if vacuum is hitting the *same* table
as my critical functions or some *other* table. 

If it's hitting the same one, there seems to be larger performance
impact, especially if I'm writing to that table. 

This is just a gut feeling, not anything scientific :)

But I guess that current release of autovacuum can't handle parallel
vacuums anyway, so I just need to do the small/fast vacuums from my own
scripts. 

This should be feasible if I can convince you of safety and usefullness
of my concurrent vacuum patch :)

-- 
Hannu Krosing <>




pgsql-hackers by date:

From: Christopher Kings-Lynne
Date:
Subject: Re: Order by optimisations?
From: Christopher Kings-Lynne
Date:
Subject: Re: Order by optimisations?