Re: Autovacuum loose ends - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Autovacuum loose ends
Date
Msg-id 1121369580.4897.14.camel@fuji.krosing.net
Whole thread Raw
In response to Re: Autovacuum loose ends  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On N, 2005-07-14 at 14:12 -0400, Tom Lane wrote:
> "Matthew T. O'Connor" <matthew@zeut.net> 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 <hannu@skype.net>



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [Bizgres-general] A Guide to Constraint Exclusion
Next
From: Simon Riggs
Date:
Subject: Re: [Bizgres-general] A Guide to Constraint Exclusion