On Mon, May 5, 2014 at 6:35 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote:
> On Mon, May 5, 2014 at 1:09 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Mon, Feb 17, 2014 at 7:38 AM, Haribabu Kommi
>> <kommi.harib...@gmail.com> wrote:
>>> I modified the "autovac_balance_cost" function to balance the costs using
>>> the number of running workers, instead
>>> of default vacuum cost parameters.
>>>
>>> Lets assume there are 4 workers running currently with default cost values
>>> of limit 200 and delay 20ms.
>>> The cost will be distributed as 50 and 10ms each.
>>>
>>> Suppose if one worker is having a different cost limit value as 1000, which
>>> is 5 times more than default value.
>>> The cost will be distributed as 50 and 10ms each for other 3 workers and 250
>>> and 10ms for the worker having
>>> cost limit value other than default. By this way also it still ensures the
>>> cost limit value is 5 times more than other workers.
>>
>> Won't this change break the basic idea of autovacuum_vacuum_cost_limit
>> which is as follows:
>> "Note that the value is distributed proportionally among the running
>> autovacuum
>> workers, if there is more than one, so that the sum of the limits of each
>> worker
>> never exceeds the limit on this variable.".
>
> It is not breaking the behavior. This setting can be overridden for
> individual tables by
> changing storage parameters. Still the cost values for the default
> tables are under the guc limit.
Could you think of a case where in current calculation it doesn't follow
what I mentioned above ("the sum of the limits of each worker
never exceeds the limit on this variable.")?
Here what I could understand is that sum of cost_limit for all
autovacuum workers should never exceed the value of
autovacuum_vacuum_cost_limit which seems to be always the
case in current code but same is not true for proposed patch.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
