> On 6 Apr 2023, at 19:18, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Apr 6, 2023 at 11:52 AM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
>>> Gah, I think I misunderstood you. You are saying that only calling
>>> AutoVacuumUpdateCostLimit() after napping while vacuuming a table may
>>> not be enough. The frequency at which the number of workers changes will
>>> likely be different. This is a good point.
>>> It's kind of weird to call AutoVacuumUpdateCostLimit() only after napping...
>>
>> A not fully baked idea for a solution:
>>
>> Why not keep the balanced limit in the atomic instead of the number of
>> workers for balance. If we expect all of the workers to have the same
>> value for cost limit, then why would we just count the workers and not
>> also do the division and store that in the atomic variable. We are
>> worried about the division not being done often enough, not the number
>> of workers being out of date. This solves that, right?
>
> A bird in the hand is worth two in the bush, though. We don't really
> have time to redesign the patch before feature freeze, and I can't
> convince myself that there's a big enough problem with what you
> already did that it would be worth putting off fixing this for another
> year.
+1, I'd rather see we did a conservative version of the feature first and
expand upon it in the 17 cycle.
> Reading your newer emails, I think that the answer to my
> original question is "we don't want to do it at every
> vacuum_delay_point because it might be too costly," which is
> reasonable.
I think we kind of need to get to that granularity eventually, but it's not a
showstopper for this feature, and can probably benefit from being done in the
context of a larger av-worker re-think (the importance of which discussed
downthread).
--
Daniel Gustafsson
