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