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.