Re: Autovacuum loose ends

On N, 2005-07-14 at 14:12 -0400, Tom Lane wrote:
> "Matthew T. O'Connor" <matthew(at)zeut(dot)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(at)skype(dot)net>