>wi_cost_limit = Max(Min(limit,
> worker->wi_cost_limit_base),
> 1);
>
> If we use the max cost_limit as the upper bound here, the worker's
> limit could unnecessarily be higher than the base value in case of
> roundoff trouble? I think that the problem here is rather that we
> don't update wi_cost_limit_base and wi_cost_delay when rebalancing the
> cost.
>
Currently, vacuum always limits you to the cost_limit_base from the time
that your vacuum started. I'm not sure why, I don't believe it's rounding
related because the rest of the rebalancing code works properly. ISTM that
looking simply allowing the updated cost_limit is a simple solution since
the rebalance code will automatically take it into account.
>
> Regards,
>
> --
> Masahiko Sawada
> EDB: https://www.enterprisedb.com/
>
>
>
--
--
Scott Mead
*sc...@meads.us *
> https://www.EnterpriseDB.com/
> "Someone said that it is at least an order of magnitude more work to do
> production software than a prototype. I think he is wrong by at least
> an order of magnitude." (Brian Kernighan)
>
--
--
Scott Mead
*sc...@meads.us *
gres
(4 rows)
postgres=# exit
postgres-# pg_dump
postgres-# pg_dump
postgres-# pg_dump
postgres-# pg_dump --help
postgres-# ls
postgres-# cd
postgres-# exit
postgres-# quit
postgres-#
It's not just usability, it's a point of serious frustration for seasoned
database people.
+1
> --
>> Michael
>>
>>
--
--
Scott Mead
Sr. Architect
*OpenSCG <http://openscg.com>*
http://openscg.com
