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

Josh Berkus wrote:

>Matthew,
>  
>
>>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?
>  
>
Well the threshold is a combination of the base value and the scaling 
factor which you are proposing is 0.1, so the threshold is base + 
(scaling factor)(num of tuples)  So with the default base of 1000 and 
your 0.1 you would have this:

 Num Rows    threshold      Percent
    1,000        1,100         110%
   10,000        2,000          20% 
  100,000       11,000          11%
1,000,000      102,000          10%

I don't like how that looks, hence the thought of some non-linear 
scaling factor that would still allow the percent to reach 10%, but at a 
slower rate, perhaps just a larger base value would suffice, but I think 
small table performance is going to suffer much above 1000.  Anyone else 
have an opinion on the table above? Good / Bad / Indifferent?

>A sliding scale would also be OK.   However, that would definitely require a 
>leap to storing per-table pg_avd statistics and settings.
>
>  
>
I don't think it would, it would correlate the scaling factor with the 
number of tuples, no per-table settings required.

>>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.
>
>  
>
That would be good to look into at some point, especially if vacuum is 
going to get slower as a result of the page loop delay patch that has 
been floating around.