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 <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
