Matthew, > 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" value? 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. -- -Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
