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 1vDWSF-00AmWa-Qk for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Oct 2025 23:16:47 +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 1vDWSE-009jy6-Mz for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Oct 2025 23:16:45 +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 1vDWSE-009jxx-DM for pgsql-hackers@lists.postgresql.org; Mon, 27 Oct 2025 23:16:45 +0000 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vDWSB-0046l4-1d for pgsql-hackers@postgresql.org; Mon, 27 Oct 2025 23:16:44 +0000 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-5930f751531so275503e87.3 for ; Mon, 27 Oct 2025 16:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761607002; x=1762211802; 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=S+H6PAW5Qdh+Y8Ld4vDAbMHtw7K8oynhtNfdMeIpKqA=; b=YpIlDrwx7L9GNS3D0hHKj1IIiWESddlCdvTfIq71eCc7sDEOmpgsBH90vAMMbxXMK+ wguP0WPckeB0NH8cOm5/65ZStRVF8+AlK3padakyKUV7iCxVCRudRJ5StZcWGbcbDg2w qs3delHNlGELKdMcU/wKUYPLRvIYX3G3BJY+NB47f8NaYS7IC7S8lF+Bmfic10cCo6xK 7wbR/JqOVmFtx9qDlEaFIYoez3uxDFMFXDO/1++XI2AYYOIvFVDQ7kJ/FRs9AG8wr99v M0WdzHqZUTgLCSv+iGTWEhp7RdvlVb3Re6qR9v4OjMTe+CVeu+1d5xmC/XMM2tpM2YRS WACw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761607002; x=1762211802; 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=S+H6PAW5Qdh+Y8Ld4vDAbMHtw7K8oynhtNfdMeIpKqA=; b=F/Olqe63UuA6wXPQlQsoYYTb+4qk+OD6pojnu+zSFhnab60i/wLNoPlL5xPPdmGIyt NP4FzAApC1ODCnZMMOnsbeoEhfUqQuC6oZ0AmMmYEWLgdpGOKBSPwF2baoh1adNyGBaN mFi+YfElDXA3B67uQJBriG7XW1w/bRqg0DGcrXRrOpHAM1DNzT8NpfTGkzX6s1pHO33p kCHo9EMi3oCcolHbzbzu45yA0LZBnzUkmnn3tI0OzQG4LtrMHRzqns1jWeUD29aXVRMA 7sbIiTIqLNpq2au8Jao7D7gzxvB/5EUe9Df0MawfkhVTdK5yynSTbXBeDRMPCjXl2oHz I9cQ== X-Forwarded-Encrypted: i=1; AJvYcCVuC/u+lPNoKMzOQfPVaPehdVZ748HK4rD40kUyikmAaZnCTT/pZWm4MpWNPExJkDpGatuZv4ZcdTHvD3f1@postgresql.org X-Gm-Message-State: AOJu0YzzeH2ENzR3+KV02HMnKnXCZOV4Ay8enqoCoGizpcs7h1jP2WT7 wOWudgRd3OBY9hXCcVjs+n2BwPAJcnM2miIfvxvgcLnBKENEgFzikJTyjB9WLsSbJjLBtNQZ439 lr7i9HT+DMOygq6VYdzS6B+m6gfHPTE8= X-Gm-Gg: ASbGncvizUW8ilra/ziCQjlSkOkyAdWrXpoqgSjZ/9edPsuw41Q8I4eaVWRYAzUSdkY hc3J1rh1dUsOdgr18EazFxJNWbbWwtl+mmfiSbBRBegzD48xe/sLSnrK4w9SiHkJzoMd5D8WrRh JRnqxt6LQgYqwGwqhZzHGNjmNRbN6SetWf8+EYipfRZV9dkh38DLHkP8vPEyf8GkQ+uxH2whCkj 7ZG6rlquOS55p+pZuRnTmiStyrGVkwsKk2JW3L/PX6yik48uF4NpgssWY3GMiUbmI6oOhuwXNn1 NQTFv+Lmu+zHm9+FIfCbHwWgfYSlgtoMngsCbZuv+6uM5HVHBSs= X-Google-Smtp-Source: AGHT+IHmRQEN7qYwN+DE/f7KffvjpowYFURBVsuF+ke43yQn3sAeMRhbRdHeCo1nezKBYMpm3Lty9lTNurzoGQgbrSI= X-Received: by 2002:a05:6512:1191:b0:593:3a3:54c5 with SMTP id 2adb3069b0e04-5930e99bbd2mr551851e87.8.1761607001443; Mon, 27 Oct 2025 16:16:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Rowley Date: Tue, 28 Oct 2025 12:16:28 +1300 X-Gm-Features: AWmQ_blDJ71ibkMruQrgFbkLj0pH_8CbPJjiNmk0KtOxhAEYX4yaeCdZf763Mlo Message-ID: Subject: Re: another autovacuum scheduling thread To: Sami Imseih Cc: Nathan Bossart , Robert Haas , Jeremy Schneider , 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 Tue, 28 Oct 2025 at 11:35, Sami Imseih wrote: > We discuss the threshold calculations in the documentation, and users > can write scripts to monitor which tables are eligible. However, there > is nothing that indicates which table autovacuum will work on next (I > have been asked that question by users a few times, sometimes out of > curiosity, or because they are monitoring vacuum activity and wondering > when their important table will get a vacuum cycle, or if they should > kick off a manual vacuum). With the scoring system, it will be much more > difficult to explain, unless someone walks through the code. I think it's reasonable to want to document how autovacuum prioritises tables, but maybe not in too much detail. Longer term, I think it would be good to have a pg_catalog view for this which showed the relid or schema/relname, and the output values of relation_needs_vacanalyze(). If we had that and we documented that autovacuum workers work from that list, but they just may have an older snapshot of it, then that might help make the score easier to document. It would also allow people to question the scores as I expect at least some people might not agree with the priorities. That would allow us to consider tuning the score calculation if someone points out a deficiency with the current calculation. Also, longer-term, it also doesn't seem that unreasonable that the autovacuum worker might want to refresh the tables_to_process once it finishes a table and if autovacuum_naptime * $value units of time have passed since it was last checked. That would allow the worker to deal with and react accordingly when scores have changed significantly since it last checked. I mean, it might be days between when autovacuum calculates the scores and finally vacuums the table when the list is long, of it it was tied up with large tables. Other workers may have gotten to some of the tables too, so the score may have dropped, but again made its way above the threshold, but to a lesser extent. David