Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s0GmW-002XkO-EY for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Apr 2024 08:18:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s0GmT-0089U6-T4 for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Apr 2024 08:18:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s0GmT-0089Tx-Du for pgsql-hackers@lists.postgresql.org; Fri, 26 Apr 2024 08:18:06 +0000 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s0GmR-0008uB-C4 for pgsql-hackers@lists.postgresql.org; Fri, 26 Apr 2024 08:18:05 +0000 Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-41ba60d69dcso448165e9.0 for ; Fri, 26 Apr 2024 01:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20230601.gappssmtp.com; s=20230601; t=1714119482; x=1714724282; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=P+Ml6VZWF7dU0bBvNJXHrU1NVW9ykaxedvNzEqwClDU=; b=OD0QPV44Z2RDKh/ucDOMMht5k7BYIS50DQgoUUby61buKA62PS+v9T5XS9zIierPdx bk+LJlvDu4XA98g8bdvutoyqv+i+amdgIdAVWB89nEYdyKYHHCvH58eE9sEZA9WTiqMI 9oo81Nf8FJsjYur3st9a8vTSH3ZQqtIrEDrzAWnce0LE8553Nrdz/BarlOY9DRz+bACZ w5X6Mae74W8T7HaiMmyfkkJX8T2+D8cyC1OM/m+CYJ4IcnFTimK+6uDL4IqcUP1ZdkLM 1jYXEednwULwpsjTjcBdotNgJxFQLGfkMlbkSi+QQxKaVGY+DtQwQt7i7ceLL4ZdHaTp 4oOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714119482; x=1714724282; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=P+Ml6VZWF7dU0bBvNJXHrU1NVW9ykaxedvNzEqwClDU=; b=FxQQzrit5j3DyxwZT9MmavkjX2NC16g1DcxPmCrKbHU4TzwX9+JOCCb+RKYYi9iu2P XouuIbKLNq8tiytPab0VrDMMpy/8jW6/xBei8u0RyvbUrLETikUV1vaoJY5DBmK7n769 L5Gr+XYjVaoWGTRCTBMKNUOiZp3CaKvjaW4JvNuqMBtRm2HrK2BDMLw3+n8L59egbVvx A4hYRTZOvxsVeMC6jNAc8eqxGKUeV8o2MopnQQybYMzW5AiuFGb47QCBrKuzmQWHiGPT MfrHjQNQSF2wg6sxdMNxPT3be/yELBGbBQ5v7wjIso/Me1rIHLUs2hMi8w9GztFYnNJI I9Tg== X-Forwarded-Encrypted: i=1; AJvYcCVpzKvqlc0eGSZCFJ3m64Os+DnmRPMlty/+RxBUl+Zqz6szMlQ7q+m+3YzFr7vDS0B0WJWUYpt6/keecgX2ZTUHn+v6bvDFhKtJf+OAGMoTi45o X-Gm-Message-State: AOJu0YwPatHPp8n7MjnVp0XUPbtE/wx6Ak3WGj7rZVBlX2YK1vy5VeHd v3IaqHcdXAe/4dGA5C0TB69B/ZiDta/iOMNUtcqJsNH923eRUKv/+meqAt337Po= X-Google-Smtp-Source: AGHT+IFzWEoi2NOnR6hr0TnGQZIhfWfgDFImV1+GrXOJiCAAChK9ai5XkacXc2S4qYlhfopcRJTKGQ== X-Received: by 2002:a05:600c:1c26:b0:41a:c170:701f with SMTP id j38-20020a05600c1c2600b0041ac170701fmr1409551wms.38.1714119482111; Fri, 26 Apr 2024 01:18:02 -0700 (PDT) Received: from localhost.localdomain ([2001:871:5e:9bed:6f6:99cd:1a72:7676]) by smtp.gmail.com with ESMTPSA id j2-20020a05600c1c0200b0041ac3e13f1esm11726812wms.37.2024.04.26.01.18.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Apr 2024 01:18:01 -0700 (PDT) Message-ID: Subject: Re: New GUC autovacuum_max_threshold ? From: Laurenz Albe To: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Yhuel , Robert Haas , Nathan Bossart Cc: Melanie Plageman , PostgreSQL Hackers , David Rowley Date: Fri, 26 Apr 2024 10:18:00 +0200 In-Reply-To: References: <956435f8-3b2f-47a6-8756-8c54ded61802@dalibo.com> <20240424195747.GA861150@nathanxps13> Autocrypt: addr=laurenz.albe@cybertec.at; prefer-encrypt=mutual; keydata=mQINBGGDwAQBEADgbWy5cKXQld3N2mF+DFyiNFbi2oBl2T+XgxpPF8wTRw2D/u4bBKXP0SYSE/lA86jIVNWWU0gf1KODIkVvgJm2w4vH2VBV1b7ddVViGl1Iu+9zaRnv9wulhnH42KefepXnoean6UT1EzLM0opF/Ik0j+40TxdRtobkBprkQUyHDXWlHc2ffPs3SipyFEP9AVLf7ejRC46CXWDnsqjOBSMEW8Z4HiK/8RrPZBsKLts8dJxKF4pygOdJb0CWk8k/X1jbcfdxo+zOLjOMvJcSJ2pFdJmQHU+JufB3rePziqQ2S9Ur6sccr9XnTC1GVBWN4Lf5VHq+vf+bFJjVwg+2hrySZnAVfcOrxoqFLErr7ug1zN2nM1kcpgA4VWn4gxlJtYNYYq+9WxX5dtvnNANlG3ZCrRKQzl8lxtzoF6Zo7LUhEqPaHDwn7Rvs+IdbOn41lF5UDTJGqmC4gS/bZydW2Fy3YWm4aSaN9fgFf8D+PVkrlKAZB7gBLz1TyHjbcRf85cYF+GKKrDld5SzMB/V60VX3oP/Eo8ikFpyWaqiz1f9X7MBot3/PjJkY+wDzp3nmb19QEcOBuQiSQ4xds2r0HewbuHTAR68u8jNNMGmpm2j4x+g09Jd/WQDjqlTBZ/jEltH41fYCCPWMfljXTOOXu2eLNGdfi7ETZogtwjM9oTtSPQARAQABtCdMYXVyZW56IEFsYmUgPGxhdXJlbnouYWxiZUBjeWJlcnRlYy5hdD6JAk4EEwEIADgWIQR0CqhbZGGABqoaSbdi8bhXA2EdmAUCYYPABAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBi8bhXA2EdmM/6EADK232JCwmBzhlj8h7U9CjG6kx0JHP3uJGv+XfsHtHAlmY/RCwF1BHMEsRlk bT5UrLvJ2jb99bA9QARzhFaxzyn0F/BUKzuIjRGNs/n6d5dNUFA0kOt8sX+TacmC GEyjEBCrVCm4ranBiUyePn9NhHNWnaex7pJyqvMLLdwW9BEMJx0Fqo+DN8ukbXmYRsmhEtd3ue+x/luYmOmJnaGtzInaY5aOJYbW9XqoRIZkZvOCgbi1FfvNmoqWa+3oVxTOgw9RafjJDyW0lTHzKGjbGI5ofMU98l+/hKJFYJqWUF6VpFJY5YIcN/1lf4ZICMwDl+MPIVo/tpq8L10seJL28nLlvw3K+cI+TVW8IW/qL/LyVoDofI3USeOORuYmhpWRhik8JXX6xf3v6GrRilJIPWNFIJbxm1ZblQiQnOw3IOW7T+8nAmPin1HKqM3VrOrJQ2VtShsefNBibNAsr1oFaqcDBkn3yGG8i6CTW+FyO4PZ+/EwNxMVgktxbYdy5AT1/lpXr5tB+phhLIyVfiBvrWs5EThxYMQ/L8Y85c3GMsAy1l/x4h3jqySIYy3SCU9+jc5UVuNnXljbvkEzJ+NLWJ6C1rACFWrMszgPdh5tCrlRY9PpmYll4JbCgb8BtxEIUmR+xr50/ZElEK5iml7Q00KUekCcDt+36PsyGFTXBzNOrkCDQRhg8AEARAAzOZ2tLHlI4rrhG411h6cdCFjBZxuljaFCxFyHn3m6wbGLqwBUWC5k8UrRqjHMz88KcTSaNO7XGAmCqPdWd2SeflPZRnNTbjsVpw7mLdffsBm4JX7kki2Pvk5h0NtYeidXT1PSpc2ri4DutYXuT9uD8RAm1wUDCE5HQNUihT/WH6opt+hskHW21uHao0+y822tG0QQcGMqdQR5Vxdxj89wiEPdqW+HpU/oOZIhrf2E7prduAppxixjHy/o1rcnoznnJvc8D3+YgI9O0LrBMij89dM55pRGbLovTR1oGR3U74sX774+0xmSzeIKwZfiMUz7Atlvfk5SHOsRUFPN2Ux9kaXiiBibQpHFxt7b lDrT4wxdLJ/XCdbPPAyl+lZtOLsaHEEZvYNyTXwZc35dVf3R4/oz20HoG6s7ct8e1 AQygj43XAERzty9SkWgxs8+grp1PrGx6FHVSYRqBM8dS/ZR6yRVwOwJXPyaSSqfIF21DkE4j1y4n+ItSewPGoRp8K/yWCikt6qlkVkO2ASNIiX04fAbtzwVOaNn8ZMRNqyvLc1fED4sr49onE4cAIcBLjcC3KL+w9DUGRQCdziROj5H2Yl/sXGPdMciUHo/Uz2rggc+2th3bQiMhrHWSsBpUkDQp0yWewemstPpPgBL3h2fHKaX8B9oH5Qu/H1IgrOuX8AEQEAAYkCNgQYAQgAIBYhBHQKqFtkYYAGqhpJt2LxuFcDYR2YBQJhg8AEAhsMAAoJEGLxuFcDYR2YuPwQAMkpGtR80pQ1gVsONhdkqj0H2eU66efP/gO3CoyaoIcvrpKYj7C2HipVSmkt1gpByL0X4AMQ/vKuknUz3wd28Ba+G1dCfbVs/Xiusq+SmpUj5rTwmYqdSjWMuCo1R6oS5hdJMdUUJYGMT0QkVlm1KnW8jkmCTl9GzjDxOAsN9O6/6lPzaGFtk9XF+34Bry/N4HKiJkqpC4+UTd0AprPfzJ2jdT64e1F0+W88X8y1bTTgNrHwK4mDiLnlE4SKRuEm54lNhJz//ar86Or5BErzNpM6TL7lk44QS06hwsMrEdKIy8J/SYJPjfzR8tIUnKscclVpOgjKaBqC+0iFiVaRqAgfOlIEiezX6kMh5Q2FIUfqs46qWhhXjRrdKOEoStYAaikdLu5ZXr7vfb0ZaDh+ZwTQtbSMFolyOkecwI81MCdbMfT/1TqIGTOdAj5as9fAakk0jb2pXgUYQ8X1DVTR8ahSDVEaw9VTmWiSvTxvguVJ1Mb7gG4Gmh6aviDTJhfXtH4rPUNXhDLqrTH8JkJjyKROOMakIF68Hjse5vUfUxreBEOtb5r1Coa2Fe7ncJayaSE7ryrDbFqpZ 36UMAx4ulWMyqJajLNGY0DdG8qIsR5nxRhrnK/mrCidZ8F9/D3bWAl4rjtHlsztN59 +AnW5l0HsQcY9ntFL/zEBOaonjdJf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 2024-04-26 at 09:35 +0200, Fr=C3=A9d=C3=A9ric Yhuel wrote: >=20 > Le 26/04/2024 =C3=A0 04:24, Laurenz Albe a =C3=A9crit=C2=A0: > > On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote: > > > I believe that the underlying problem here can be summarized in this > > > way: just because I'm OK with 2MB of bloat in my 10MB table doesn't > > > mean that I'm OK with 2TB of bloat in my 10TB table. One reason for > > > this is simply that I can afford to waste 2MB much more easily than I > > > can afford to waste 2TB -- and that applies both on disk and in > > > memory. > >=20 > > I don't find that convincing. Why are 2TB of wasted space in a 10TB > > table worse than 2TB of wasted space in 100 tables of 100GB each? >=20 > Good point, but another way of summarizing the problem would be that the= =20 > autovacuum_*_scale_factor parameters work well as long as we have a more= =20 > or less evenly distributed access pattern in the table. >=20 > Suppose my very large table gets updated only for its 1% most recent=20 > rows. We probably want to decrease autovacuum_analyze_scale_factor and= =20 > autovacuum_vacuum_scale_factor for this one. >=20 > Partitioning would be a good solution, but IMHO postgres should be able= =20 > to handle this case anyway, ideally without per-table configuration. I agree that you may well want autovacuum and autoanalyze treat your large table differently from your small tables. But I am reluctant to accept even more autovacuum GUCs. It's not like we don't have enough of them, rather the opposite. You can slap on more GUCs to treat more special cases, but we will never reach the goal of having a default that will make everybody happy. I believe that the defaults should work well in moderately sized databases with moderate usage characteristics. If you have large tables or a high number of transactions per second, you can be expected to make the effort and adjust the settings for your case. Adding more GUCs makes life *harder= * for the users who are trying to understand and configure how autovacuum wor= ks. Yours, Laurenz Albe