> 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.

-Josh Berkus
 Aglio Database Solutions
 San Francisco

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to