> Basically, I don't like the idea of modifying users databases, besides,
> in the long run most of what needs to be tracked will be moved to the
> system catalogs. I kind of consider the pg_autvacuum database to
> equivalent to the changes that will need to be made to the system catalogs.
OK. As I said, I don't feel strongly about it.
> I certainly agree that less than 10% would be excessive, I still feel
> that 10% may not be high enough though. That's why I kinda liked the
> sliding scale I mentioned earlier, because I agree that for very large
> tables, something as low as 10% might be useful, but most tables in a
> database would not be that large.
Yes, but I thought that we were taking care of that through the "threshold"
A sliding scale would also be OK. However, that would definitely require a
leap to storing per-table pg_avd statistics and settings.
> Only that pg_autovacuum isn't smart enough to kick off more than one
> vacuum at a time. Basically, pg_autovacuum issues a vacuum on a table
> and waits for it to finish, then check the next table in it's list to
> see if it needs to be vacuumed, if so, it does it and waits for that
> vacuum to finish.
OK, then, we just need to detect the condition of the vacuums "piling up"
because they are happening too often.
Aglio Database Solutions
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]