> On 6 Apr 2023, at 19:18, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Apr 6, 2023 at 11:52 AM Melanie Plageman > <melanieplage...@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
