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 1pWeF2-0001p7-L2 for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Feb 2023 14:12:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pWeF0-000145-HF for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Feb 2023 14:12:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWeF0-00013w-5f for pgsql-hackers@lists.postgresql.org; Mon, 27 Feb 2023 14:12:34 +0000 Received: from mail-oa1-x30.google.com ([2001:4860:4864:20::30]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pWeEx-0001Q2-GL for pgsql-hackers@postgresql.org; Mon, 27 Feb 2023 14:12:33 +0000 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-17213c961dfso7570517fac.0 for ; Mon, 27 Feb 2023 06:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=75a3mSECtYb3IuEdSN5zP2jX/dfjjDto+R1Y7+fvlZQ=; b=EZ3AJeyLMN4PwdJXzRwE9nIV91oqHG73OKpClX7fY/kdMRfi6PLOhg1QPLVzsICYYJ jqdSq8vz1zfXeGr7KS9DhYKGvY9GzNWLC5RuI9/yNwo/MRbZC8/E06rcO7cr95LhHunq vru/FVgBaoHeNbqf/eM2i4EKtbL7PNOxRx2Va9WMDuAFwUgKTpvp60xtelJNY7aEGX1u 7Ex5ENNsBzOHgerZZfILfOiDbqsoHkip72oplC0Xn/eqY8P9lyDkP/ErXQP44RpJLNIb 2y/IcZw6+qFdqcA8flBRHmL/xmta6fjP9oxTUpRO7jaeb0gdJqlAjyRaYffrZYy9PYOP u37Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=75a3mSECtYb3IuEdSN5zP2jX/dfjjDto+R1Y7+fvlZQ=; b=3odMyyRMILvuEysHzu0h2/4Qk7opWfejCFUaU4Fkz4zNjTFhSnw5MyvsnFzwvA+X0p +SInNwjFrrBlrtWtI3QBPOBrUkm7fVc75aJUvu21aAApStFK2n6BWQLYNlni6gCNrnHL vNjZMOfvJEmjbdBEGUw1/KHrzFaxwtQKkE0cXK3Zs4b3aYL5uNv1Dl4PwzWZhsttYIw8 syJlxzdhoefNN284gcGr5XLzpoyokQKf4n4pfAF5ZWKzESejkBTDHS0QRGQJlRCDVHVm x7w9lQ7VdkPFoMhltbRdLY5otbX/Js8O7RljGvsFVznGekJu9Zwt1ZF+sf+Ry19ohc10 xJHA== X-Gm-Message-State: AO0yUKXbIEGZtDJ4GwmVpFMnSzmBVN2dShdTV8t2fOJHT4W2RQD/soxn dGMQ6qMmQq5HblFbUSLbPzpulxn0tqYuZ7E7jFQ= X-Google-Smtp-Source: AK7set88ptmqXWtYBZQkvWGb+kLtaquU2eGa77I8V3HKLFGQWztSWVLtpEW83mKseiSKnR4OQESrXhr43CXHhTX8kbk= X-Received: by 2002:a05:6870:9883:b0:172:6cff:b00e with SMTP id eg3-20020a056870988300b001726cffb00emr3506296oab.7.1677507149738; Mon, 27 Feb 2023 06:12:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Masahiko Sawada Date: Mon, 27 Feb 2023 23:11:53 +0900 Message-ID: Subject: Re: Should vacuum process config file reload more often To: Melanie Plageman Cc: Pg Hackers , Andres Freund Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Fri, Feb 24, 2023 at 7:08 AM Melanie Plageman wrote: > > Hi, > > Users may wish to speed up long-running vacuum of a large table by > decreasing autovacuum_vacuum_cost_delay/vacuum_cost_delay, however the > config file is only reloaded between tables (for autovacuum) or after > the statement (for explicit vacuum). This has been brought up for > autovacuum in [1]. > > Andres suggested that it might be possible to check ConfigReloadPending > in vacuum_delay_point(), so I thought I would draft a rough patch and > start a discussion. In vacuum_delay_point(), we need to update VacuumCostActive too if necessary. > Apart from this, one higher level question I have is if there are other > gucs whose modification would make reloading the configuration file > during vacuum/analyze unsafe. As far as I know there are not such GUC parameters in the core but there might be in third-party table AM and index AM extensions. Also, I'm concerned that allowing to change any GUC parameters during vacuum/analyze could be a foot-gun in the future. When modifying vacuum/analyze-related codes, we have to consider the case where any GUC parameters could be changed during vacuum/analyze. I guess it would be better to apply the parameter changes for only vacuum delay related parameters. For example, autovacuum launcher advertises the values of the vacuum delay parameters on the shared memory not only for autovacuum processes but also for manual vacuum/analyze processes. Both processes can update them accordingly in vacuum_delay_point(). Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com