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 1v6f4U-007uE9-JK for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Oct 2025 01:03:54 +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 1v6f4S-00E3Qr-3P for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Oct 2025 01:03:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v6f4R-00E3QW-Nl for pgsql-hackers@lists.postgresql.org; Thu, 09 Oct 2025 01:03:52 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v6f4Q-000lAG-01 for pgsql-hackers@postgresql.org; Thu, 09 Oct 2025 01:03:51 +0000 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-3635bd94dadso3290491fa.1 for ; Wed, 08 Oct 2025 18:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759971827; x=1760576627; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QGI3ypbKM0a+9c7vXApUX/ybpVJYwADkQuQYpKBwS40=; b=TbVi3l18g8x+/PKnK7gZI84Z5JeJHSbPDpkBeaMZcvLhhABu/VCfRiEWkAwfJCkCmy AlHqQddluhbWDhiZV8Sw2LABtdfLjn7y6K5k7CzJym+bJNxaLifoYzSYyh7dCzafGDsI vl3mYJKd+GktH9EPgL6DeaQjxVUBuwAABh3e3cXNbgC0QHzbds7/lo4TE3DzLcgrhtCy WOb/mA+8ovIc6xTo4NivaVfckijW34vfMuGesYWmEJW/IM6TEcG3Szq02dqC0nt94JN6 e4Mbx0++Y4HtbQ8RY0cz/CmjP02M7uAYxD7+QhCJ+KN5zLaSlCmoa7WNFx00B8q5E6Ce Xkxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759971827; x=1760576627; 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=QGI3ypbKM0a+9c7vXApUX/ybpVJYwADkQuQYpKBwS40=; b=pN/HQvlZsGXZLptuzpCoOCLzCVMWz6HKnwuMzHOTqMOuyGgzTYtX4imWx0yMe0p4zK kNbLsG5aQ+rQLmsL9aUd6Oj+l/Ifc4uVIS5UcjrWSwch8EwjS3AoG5WFnN1zbkZIJ/Y1 TWWchczYPbPKBdTHX7yWyTlDvv74XMWAu6JwzjG5h3a/Gv+ELiEMg43j6Y2S1Le1q1/P O7IpWBdUjuNfZNleuyvIgE4b9A0t0KmmBFzJWgfSZnhNgxl5gqMUDYRBAoMIeEHy8F0G rLHlXmMYMBtHmLKS/eAB81XXeIQcLmsVUIOMHaK6sSzzWa/ret3F71u0bm0R8udMD6k4 dYyQ== X-Forwarded-Encrypted: i=1; AJvYcCW6R2+qY4JeRuAT3H0xzGHTjSauPu+rMHgZnxsVtp+bUS37XJFeafpFPZASh2TP4vTcV9buzuAxmceUFWpH@postgresql.org X-Gm-Message-State: AOJu0YwBqQ0REd6B+CAPzOUDDnQLecKSOuAG0LcuUFqLwItENW730cjH 6L9gzOQnjI3mIcinLZikbdl9ZhERWlPyPKc+r2J/0gbLi75ArAvLdOUQWhKSALs333Ew7G6XyP2 Un5bAgRETbdpBlQw6WfWsC3Q8izGUYFc= X-Gm-Gg: ASbGnctd8odx4ACctk1cjN0v/9QOf13cTLI1FjoxAeqTjyP8zc+jRc8gDuF3mC5RRSj E0ctMuzToMRspwmMFr8dUrIBCGcyIP5qJH6UsjW/h9exdmNhw0AsYwtotl1NdT9iFQCk0kEQp5Q iLf8IuJV+n3S25MIuaEOqbUMcOuVZs67XHLDVnZz5/ElfAPnMprYh864aRkonDMpI3TggF2nahS yGL5wZFVv90etMM6nRgrnEwQpSJixpqrnpPqQPuoHf+GSA4K7d0TU1buO7XE9M4HNeyqi9cvf8g 4AoGF7WvTBe0h5EksVvtCw== X-Google-Smtp-Source: AGHT+IEeUX+nqpqWsaL2ZgQlLXXOnbqlmhQNknCfl9eT7r9TF0YHaYm0Hmvj/ZqARhtxpxo6+24i0RZnc7KMIKBfEWg= X-Received: by 2002:a05:651c:1593:b0:375:ff2b:14ee with SMTP id 38308e7fff4ca-37609e8ca90mr15135451fa.29.1759971827227; Wed, 08 Oct 2025 18:03:47 -0700 (PDT) MIME-Version: 1.0 References: <20251008164057.6bceb9ed@ardentperf.com> <20251008172727.3befd129@ardentperf.com> In-Reply-To: <20251008172727.3befd129@ardentperf.com> From: David Rowley Date: Thu, 9 Oct 2025 14:03:34 +1300 X-Gm-Features: AS18NWCCt7S3MIJgpipXRzRaFqYZq0PPP7ZlpzRhflhWhEpm6xSQqkCN9RU3zfI Message-ID: Subject: Re: another autovacuum scheduling thread To: Jeremy Schneider Cc: Sami Imseih , Nathan Bossart , pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 9 Oct 2025 at 13:27, Jeremy Schneider wrote: > I'm arguing that it works well with autovacuum. Not saying there aren't > going to be certain workloads that it's suboptimal for. We're talking > about sorting by (M)XID age. As the clock continues to move forward any > table that doesn't get processed naturally moves up the queue for the > next autovac run. I think the concerns are minimal here and this would > be a good change in general. I thought if we're to have a priority queue that it would be hard to argue against sorting by how far over the given auto-vacuum threshold that the table is. If you assume that a table that just meets the dead rows required to trigger autovacuum based on the autovacuum_vacuum_scale_factor setting gets a priority of 1.0, but another table that has n_mod_since_analyze twice over the autovacuum_analyze_scale_factor gets priority 2.0. Effectively, prioritise by the percentage over the given threshold the table is. That way users could still tune things when they weren't happy with the priority given to a table by adjusting the corresponding reloption. It just seems strange to me to only account for 1 of the 4 trigger points for autovacuum when it's possible to account for all 4 without much extra trouble. David