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 1vCpWN-0014v0-1Z for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Oct 2025 01:26:10 +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 1vCpWJ-004Fr1-L7 for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Oct 2025 01:26: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 1vCpWJ-004Fqt-9N for pgsql-hackers@lists.postgresql.org; Sun, 26 Oct 2025 01:26:06 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vCpWF-004FJg-29 for pgsql-hackers@postgresql.org; Sun, 26 Oct 2025 01:26:05 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-591c9934e0cso5001662e87.0 for ; Sat, 25 Oct 2025 18:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761441960; x=1762046760; 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=TDW1nsvAl0c6NmPoD05xzZdyXrOt8+OBo7k95v3JnZI=; b=Enc8QB8i5z0NYas8k0b83GHqwqjPvDII+nuIEJDVbRltD3p0jg9vRuXHS2DTHi3zVD ey7+uqGWy0GEUgUd1BacdRCJfTHYKDsdsgjo4d1QdZdenUfyqiH57XFQCggsrolni0NR yCOFYh6bKpIqso6sH3d1kk9eXu4U+S/hlPjhpktA+mfhZ+VeRd3RbboPcm4rtYJ/75UU dUbWGrZgDTN9FMhAG1atldxoMCgb0Y8JRclvc9JrxWPJoK+GL5akWs7FVV2ExgxnvZpI G9Tn+qvUOIiPeT8hd5jZ3TZ2Ik5urErEHg6BSHQZq81bd3XGEAlAuPoqRB2nznT662Ov LHmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761441960; x=1762046760; 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=TDW1nsvAl0c6NmPoD05xzZdyXrOt8+OBo7k95v3JnZI=; b=Z/9XBdC1lA9xzCi9/VRCdcm1WSXfcbCcb50vCoYcmSwYUsi+eUJjTZUSfERIhGJt7D J7b9FgA8+Y2rJE3pxqcmsf4P4rVW6Y0MBcDEVrGKZ27DdDlTF2Qs0ueBE9yV6HqqmQ0w 5jRLRL+eVgNvNJu2DEPabqRT7w0kldxXbDlJeQ2gpi3jAEie0vsA7WoQ35yoSWYEzd5i KzMFatYg/snQ8gaqSKELjxKMj+u0iyGbkMLoivoBpejlKERjeLkI+W3ch6/C4a2IWXA1 NMH6xdefDLrqry2vHXLoMp9wqjx2tflOotAzyuAK4EExDe9l3eiQfkqvy6pDoUlSKyWw Hs+g== X-Forwarded-Encrypted: i=1; AJvYcCUoOHzIwt4KC3ksZZPaXkNZWuItMpFOrZpILI9dLwFZ42isHyIIbzaMgxdbKLiGeblDUBFPWHpXb6xlQUcN@postgresql.org X-Gm-Message-State: AOJu0YyxtSPYC+6xmLERacroVxNnojUaZXe1vNr7zxdu/HrRCkCiH4eL 4Obb8g1ZSQDc2wsqfaqs4C+8qMrbcr2nuv3rpnN4UF5i/VzA8rpPDcRszP/EP6UoFW6xM7KPpS5 j6XgZEzd46y9Q0rIJdkgMxyF+izQx5VI= X-Gm-Gg: ASbGncsLC0S/Xg7Qth3id6Xk4XfJz8+3Le6JzMrizHnGZpXN51zCbvEn2lzNUt88iei nUH0MyPUc7m+5C6eGQmIy3fVPOW8/olNi3hsxWRJDB984txMjlTm/FSXlN5BCp7+Uh0dNfvcg4t 5KoJyGeaKHJUM/Vg6jH4hsUTFWTZ6GGhnF/YZxSPddcA+2al0um9VRjYW7kjVYdUQq06/3obrr1 LBbCi/0G8Z2RGDhcHI4iD5BLdCQIu31iFgbsBIyMfR4LKwp8Krl5UR91iMDpFmAK0/gTSbsVcKz uYRye6iR88/1S4Wd/2/rvYETSMEFE23a7qPxF6jY+8gKDT1yabg= X-Google-Smtp-Source: AGHT+IFnCCWVT3PcmZJ+/r7m6LkvEwz6Sw+pkPOL+fv9VLI23+KqgaRfXt+KTqmd2uK57ESWVIMUl07k23FPbJbRt0I= X-Received: by 2002:a05:6512:39ce:b0:567:68ad:427a with SMTP id 2adb3069b0e04-591d8443c7emr9959949e87.0.1761441960173; Sat, 25 Oct 2025 18:26:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Rowley Date: Sun, 26 Oct 2025 14:25:48 +1300 X-Gm-Features: AWmQ_bnMM76bdOoZiiRvEBEyAXNUSvZ2mi1yfz8QaLmbCS3knfo5Iv8UXHTRlVs Message-ID: Subject: Re: another autovacuum scheduling thread To: Nathan Bossart Cc: Sami Imseih , 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 Sat, 25 Oct 2025 at 04:08, Nathan Bossart wrote: > Here is an updated patch based on the latest discussion. Thanks. I've just had a look at it. A few comments and questions. 1) The subtraction here looks back to front: + xid_age = TransactionIdIsNormal(relfrozenxid) ? relfrozenxid - recentXid : 0; + mxid_age = MultiXactIdIsValid(relminmxid) ? relminmxid - recentMulti : 0; 2) Would it be better to move all the code that sets the xid_score and mxid_score to under an "if (force_vacuum)"? Those two variables could be declared in there too. 3) Could the following be refactored a bit so we only check the "relid != StatisticRelationId" condition once? + if (relid != StatisticRelationId && + classForm->relkind != RELKIND_TOASTVALUE) Something like: /* ANALYZE refuses to work with pg_statistic and we don't analyze toast tables */ if (anltuples > anlthresh && relid != StatisticRelationId && classForm->relkind != RELKIND_TOASTVALUE) { *doanalyze = true; // calc analyze score and Max with *score } else *doanalyze = false; then delete: /* ANALYZE refuses to work with pg_statistic */ if (relid == StatisticRelationId) *doanalyze = false; 4) Should these be TransactionIds? + uint32 xid_age; + uint32 mxid_age; 5) Instead of: + double score = 0.0; Is it better to zero the score inside relation_needs_vacanalyze() so it works the same as the other output parameters? David