Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pkUlJ-0007vB-Se for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Apr 2023 18:55:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pkUlI-0007d8-Nm for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Apr 2023 18:55:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pkUlI-0007cw-E7 for pgsql-hackers@lists.postgresql.org; Thu, 06 Apr 2023 18:55:08 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pkUlF-0003lR-R1 for pgsql-hackers@postgresql.org; Thu, 06 Apr 2023 18:55:07 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 8B02A2F7F089 for ; Thu, 6 Apr 2023 20:55:03 +0200 (CEST) Received: from s981.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id 7A8482E294B0; Thu, 6 Apr 2023 20:55:03 +0200 (CEST) Received: from s472.loopia.se (unknown [172.22.191.6]) by s981.loopia.se (Postfix) with ESMTP id 7642E22B1744; Thu, 6 Apr 2023 20:55:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1] autolearn=disabled Received: from s899.loopia.se ([172.22.191.6]) by s472.loopia.se (s472.loopia.se [172.22.190.12]) (amavisd-new, port 10024) with LMTP id cPlp2qQ0gPxS; Thu, 6 Apr 2023 20:55:03 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: daniel@yesql.se X-Loopia-Originating-IP: 89.255.232.193 Received: from smtpclient.apple (customer-89-255-232-193.stosn.net [89.255.232.193]) (Authenticated sender: daniel@yesql.se) by s899.loopia.se (Postfix) with ESMTPSA id C7CB72C8BA4D; Thu, 6 Apr 2023 20:55:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) Subject: Re: Should vacuum process config file reload more often From: Daniel Gustafsson In-Reply-To: Date: Thu, 6 Apr 2023 20:55:02 +0200 Cc: Melanie Plageman , Andres Freund , Tom Lane , Masahiko Sawada , Kyotaro Horiguchi , PostgreSQL Hackers , Amit Kapila Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230329.132155.629765142788133576.horikyota.ntt@gmail.com> <20230329.173456.1185961934810139447.horikyota.ntt@gmail.com> <935191FB-083B-4060-89FC-466F61FAA391@yesql.se> <1252075.1680547394@sss.pgh.pa.us> <20230403190837.qubpnwugfe2k2g46@awork3.anarazel.de> <7E06F879-7E20-4A6A-862F-CA72CDC9A323@yesql.se> To: Robert Haas X-Mailer: Apple Mail (2.3696.120.41.1.2) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 6 Apr 2023, at 19:18, Robert Haas wrote: >=20 > On Thu, Apr 6, 2023 at 11:52=E2=80=AFAM Melanie Plageman > 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... >>=20 >> A not fully baked idea for a solution: >>=20 >> 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? >=20 > 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