Re: [HACKERS] More detail on settings for pgavd?

Josh Berkus wrote:

>Matthew,
>
>  
>
>I don't see how a seperate database is better than a table in the databases., 
>except that it means scanning only one table and not one per database.   For 
>one thing, making it a seperate database could make it hard to back up and 
>move your database+pg_avd config.
>  
>
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.

I guess it could make it harder to backup if you are moving your 
database between clusters.  Perhaps, if you create a pg_autovacuum 
schema inside of your database then we would could use that.  I just 
don't like tools that drop things into your database.

>>Where are you getting 13% from? 
>>    
>>
>
>13% * 3/4 ~~ 10%
>
>And I think both of use agree that vacuuming tables with less than 10% changes 
>is excessive and could lead to problems on its own, like overlapping vacuums.
>
>  
>
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.

>> Do you know of an easy way to get a 
>>count of the total pages used by a whole cluster?
>>    
>>
>
>Select sum(relpages) from pg_class.
>
>  
>
duh....

>BTW, do we have any provisions to avoid overlapping vacuums?  That is, to 
>prevent a second vacuum on a table if an earlier one is still running?
>
>  
>
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.   There was some discussion of issuing concurrent 
vacuum against different tables, but it was decided that since vacuum is 
I/O bound, it would only make sense to issue concurrent vacuums that 
were on different spindles, which is not something I wanted to get 
into.  Also, given the recent talk about how vacuum is still such a 
performance hog, I can't imagine what multiple concurrent vacuums would 
do to performance.  Maybe as 7.5 develops and many of the vacuum 
performance issues are addressed, we can revisit this question.