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 1vBdkz-001xfJ-MU for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Oct 2025 18:40:21 +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 1vBdkx-000iaN-H3 for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Oct 2025 18:40:18 +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 1vBdkx-000iaC-71 for pgsql-hackers@lists.postgresql.org; Wed, 22 Oct 2025 18:40:18 +0000 Received: from mail-il1-x12e.google.com ([2607:f8b0:4864:20::12e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vBdku-003f1z-0Z for pgsql-hackers@postgresql.org; Wed, 22 Oct 2025 18:40:17 +0000 Received: by mail-il1-x12e.google.com with SMTP id e9e14a558f8ab-431d2ca8323so8438125ab.3 for ; Wed, 22 Oct 2025 11:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761158414; x=1761763214; darn=postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=glCtZtUYJqIIrhU8yquWyAQuUVx3CTvfCihO0U8fqzE=; b=IQ69ReIPlZkIVz0SJD1acQK0A3vwPa93rxOr0hdiXaaYWkTf0cNuz9l3wqDtRv/L86 7V9Ay0BJOCnh6yY3yG+11NJEB0GitE534XXz+nYAnu4i5wd3dMeHSq1UErYVXf+qYKfa Y7dkxyDNCP690UaebvinMS4YVoK961xwlqBEmmaoREySwG/vqqhJfvh+T64NNiGg6+iH qdXB3x8E1WZxTctxOXTKJHdxwnnvpJ6bfNsZM7fj338MqyI6FKjV5Qnre5INX1ewz02S mz8Syg79Rbhc6STba7hRxGGRkRvHumIszsXF+cH5L/nqKMiaXueOrz0LaPWOZMuTdNn4 Rv8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761158414; x=1761763214; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=glCtZtUYJqIIrhU8yquWyAQuUVx3CTvfCihO0U8fqzE=; b=IhVMCb6qUXObXwSa5hQsSzSVwWAVfPDImI39VijrgVsOA3PkLADZKqUaPgaml2Mw+j rZzyma1virALobtDJlsOq9djMDcSv8B9sOSniwx0xrQ72sGajONlTGNjAmwat+qZItTz zn49zpvn4D9JpgaKuQVkMRZd+FA47bR5/aA7gM8q80h9SyMaxKJMFQ2GzdXjn6+1mpam z9N32kVBOdHqGxePk+/946YoV+T4ZAsACJ5BOWJDyWRK7G991Y/Jc9kW3w44ZkeyqXzA uS+wKlRrJmNmnEuugrwqfeD2ZsRWOo0Fs9+itWju2i3AMsMv3gIkGKdh7qKyZbDLfH2u fTCg== X-Forwarded-Encrypted: i=1; AJvYcCU0htT1N6sIOL86VFAtgMMavrM2T+bkqmSw8XHt5lNktgu9rdXxlUX9f3u+Tz7YV4FJGDyLMXVEcpmN+Cbr@postgresql.org X-Gm-Message-State: AOJu0YwzvGkS52Wmq9diGJ7dsPF7OpMk0Es/7Fm6IWMaZ76SiC2ItoOy AY/IGaUfdwlCJTDcUusAS8gI4GNT1nP2xiaauYYpBwMOv91kBvBmdHbW X-Gm-Gg: ASbGncvw05YjaG9uMjIluUNlubG3y03BK4Pz5Eemnsg9S6Yhh2h9TKL8JpfseIBbgVi DVOb10PbJUl0kTz6ftbMeOmg7FUxIrlMX+GvHpPBW1ro6uKmKfWYKM9qf9frOFSlvvuYKP2j4QC TOvv8ErZ9gFyHPYoHlN1hqfrgnToJHin5psKLqEntRghlYaP1h9SYnjVRUSzCXhQuAL0UpKU+tQ Bq6f3TtSULw36a4S0Qc2KxgpGofVwE2XyUBGtwXOkIcHA4ztCLOzpIvfah4GV3nSliuOcIpEpHN MxoP07ayI+ojuxsMB0QjRWcvupA+UotO8znWOPM/wo1xog/vrhnasWqtuU/tN2qfGwSPcaMO7S1 oK/+OJzbs9Gx6vTd5JWtZvGS6qeuUujrFcWAKKrM+alIfnZl1yvm5a6AEQ0x2afVhHHl0FON/MP pYQ/T0lVm6/U4Kn9UEErVdQekqzUOfgKDmfcAu56+kYs7BxyDNGRY+UZ7bot7PYFYJ/89wRc98O VfF X-Google-Smtp-Source: AGHT+IG6UAaAcSxU7oPwRTJ9n+PwAEVLtWoyRhkDcjfHS5N/Ff5ZetkoiB2CmIr7vdZ70Z+bMONThQ== X-Received: by 2002:a05:6e02:178e:b0:430:d061:d9f7 with SMTP id e9e14a558f8ab-430d061da22mr247166185ab.23.1761158413870; Wed, 22 Oct 2025 11:40:13 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-5ab76df0cb6sm151946173.1.2025.10.22.11.40.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Oct 2025 11:40:13 -0700 (PDT) Date: Wed, 22 Oct 2025 13:40:11 -0500 From: Nathan Bossart To: David Rowley Cc: Robert Haas , Jeremy Schneider , Sami Imseih , pgsql-hackers@postgresql.org Subject: Re: another autovacuum scheduling thread Message-ID: References: <20251008182520.6e05a8b8@ardentperf.com> <20251008184740.328d45de@ardentperf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Oct 22, 2025 at 09:07:33AM +1300, David Rowley wrote: > However, just thinking of non-standard setting... I do wonder if it'll > be aggressive enough if someone did something like raise the > *freeze_max_age to 1 billion (it's certainly common that people raise > this). With a 1.6 billion vacuum_failsafe_age, a table at > freeze_max_age only scores in at 110. I guess there's no reason we > couldn't keep your calc and then scale the score further once over > vacuum_failsafe_age to ensure those are the highest priority. There is > a danger that if a table scores too low when age(relfrozenxid) > > vacuum_failsafe_age that autovacuum dawdles along handling bloated > tables while oblivious to the nearing armageddon. That's a good point. I wonder if we should try to make the wraparound score independent of the *_freeze_max_age parameters (once the table age surpasses said parameters). Else, different settings will greatly impact how aggressively tables are prioritized the closer they are to wraparound. Even if autovacuum_freeze_max_age is set to 200M, it's not critically important for autovacuum to pick up tables right away as soon as their age reaches 200M. But if the parameter is set to 2B, we _do_ want autovacuum to prioritize tables right away once their age reaches 2B. > Is it worth writing a comment explaining the philosophy behind the > scoring system to make it easier for people to understand that it aims > to standardise the priority of vacuums and unify the various trigger > thresholds into a single number to determine which tables are most > important to vacuum and/or analyze first? Yes, I think so. > Thanks for working on this. I appreciate the discussion. -- nathan