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 1nFqSI-00015V-0s for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Feb 2022 04:44:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nFqSG-0004kc-FW for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Feb 2022 04:44:16 +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 1nFqSG-0004kT-2p for pgsql-hackers@lists.postgresql.org; Fri, 04 Feb 2022 04:44:16 +0000 Received: from mail-io1-xd2f.google.com ([2607:f8b0:4864:20::d2f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nFqSB-0000uI-QF for pgsql-hackers@lists.postgresql.org; Fri, 04 Feb 2022 04:44:15 +0000 Received: by mail-io1-xd2f.google.com with SMTP id e79so5930518iof.13 for ; Thu, 03 Feb 2022 20:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=v/H36xxhYCcEvG+Mms7FaUJC3GAQOHKU5q4Nf477Blc=; b=x0qwkLyNQnB0OR0878lh/Xx/5hcD9xgcHmZ+EzmVZt9weLjVMlJgUXd9CZk7ukinCD P10NPeEL6daIbi/M/DcECN/z560ABLVJF7F3FtknQbAmGGfQC0hTSmNH69gzfVJU3GkQ n2nTvtfAoejmCT3zAge4tvNDPZ+4ev9QJ1horO/IsIXAD/KI7FpW5T8r2eDZHIzg2pqP LcgPihViVnoCulLL7I1er6VBtrXNXOrZYIlkfEGOFP5Bgx8C3IImtB4DO29rFO4ui5XH 6Lk50k5qolWa8vyRAoQtRz5md66o6X6e54iSe6toOEmxAAgzUBps1TQLt1Ydsl8qrgrM 6C8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=v/H36xxhYCcEvG+Mms7FaUJC3GAQOHKU5q4Nf477Blc=; b=IQa7Oo+0Wo/v1vPT023CovIWtxkKmM0AEqFbEsJ3wE/P8i+N6/G/SFtDjTtYbUOjBm 75B6JdcNuWot+NVJBgPW/KByZSbtcM9g7mgDC3aec/dgxR8l7k8YkUS2tuu5q14xBKzd BvyXtuhAAlYf0vhEqpOfTZiMt56WI6VCczH8BrXFlRoJdUS+ZuuBp2tK7iK6mZ4sOweH 5in79B5HMAT7GADyuROdp8f8UVRcl8WlENXdrrafmPpmBwXuCDehSVGAgaaGqYEDB61j pdH75dz7Xm0OrNtsAzNTRrsHWbj4WL+P2qNzWpR97A9sm9poHUpQa+PEPWtgkSc2AT1/ 1NiA== X-Gm-Message-State: AOAM5330NFu1Kmis8DLJ2Ex0mCWE+OHtIxLjqa+jiw9P7g6faa5Pthmd 6iJrZcIE5wt+itASpUWd95SdZw== X-Google-Smtp-Source: ABdhPJxw57swCupELzej566Ag+TGkJmuUnYu7jc3PAxShQnd75pNSTHrT3vs4FK0Eh6HKJh7jbbo4w== X-Received: by 2002:a05:6638:3045:: with SMTP id u5mr572485jak.105.1643949848291; Thu, 03 Feb 2022 20:44:08 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id x24sm433384iox.20.2022.02.03.20.44.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Feb 2022 20:44:07 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 2D27C80076A; Thu, 3 Feb 2022 22:44:07 -0600 (CST) Date: Thu, 3 Feb 2022 22:44:07 -0600 From: Justin Pryzby To: Andres Freund Cc: Robert Haas , John Naylor , Peter Geoghegan , pgsql-hackers@lists.postgresql.org, Masahiko Sawada Subject: Re: do only critical work during single-user vacuum? Message-ID: <20220204044406.GK23027@telsasoft.com> References: <20211210015616.o242b4xchhpglfcy@alap3.anarazel.de> <20220203215048.rmwjzixdzaetedxq@alap3.anarazel.de> <20220204013539.qdegpqzvayq3d4y2@alap3.anarazel.de> <20220204032601.qwy3tetzp3o4djxc@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220204032601.qwy3tetzp3o4djxc@alap3.anarazel.de> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Feb 03, 2022 at 07:26:01PM -0800, Andres Freund wrote: > Which reminds me: Perhaps we ought to hint about reducing / removing > autovacuum cost limits in this situation? And perhaps make autovacuum absorb > config changes while running? It's annoying that an autovac halfway into a > huge table doesn't absorb changed cost limits for example. I remembered this thread: https://commitfest.postgresql.org/32/2983/ | Running autovacuum dynamic update to cost_limit and delay https://www.postgresql.org/message-id/flat/13A6B954-5C21-4E60-BC06-751C8EA469A0%40amazon.com https://www.postgresql.org/message-id/flat/0A3F8A3C-4328-4A4B-80CF-14CEBE0B695D%40amazon.com -- Justin