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.96) (envelope-from ) id 1vIubG-002Uws-2K for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Nov 2025 20:04:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vIubD-007UBO-0k for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Nov 2025 20:04:19 +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.96) (envelope-from ) id 1vIubC-007UBE-31 for pgsql-hackers@lists.postgresql.org; Tue, 11 Nov 2025 20:04:18 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vIub7-007DA7-0C for pgsql-hackers@postgresql.org; Tue, 11 Nov 2025 20:04:18 +0000 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-59457f79859so68617e87.2 for ; Tue, 11 Nov 2025 12:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762891447; x=1763496247; 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=bhsJh85ar6tYfZ2oxoEmSBfzGzRZ6YiW1Emc9lARNyA=; b=IhuhR7OmAvG4d6gWgL7c+Y6jDVgTiRHbtuLFPBWyYnqq9z7UgdFf4oQJ1FhXdPSxfW UBDonlEBIaPmT1XOa2Ek5XfejuJf0WHN9HI0UkIZFcLQ6njl7W9rEWCkzFcMF1MNcqGn 2T7s/S5C6oSuPsFdvTOzjgyw5BZ6vWpv8nco4uuxB/vEGlYeA5ZKbFO5YEUX0i7/Su8d Xu/ylpXMZLghbeajn2ojM2qB0VRYl9HaIS93SmWS6xja06yvWxQVG1Z4YDpC80PbAQtu A0UgmNdw4gvGOek9Uuv98VD3JInwPVwZVZLtAd++F4C1caJvG81snglu/h7Vma+A7h3m EfjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762891447; x=1763496247; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bhsJh85ar6tYfZ2oxoEmSBfzGzRZ6YiW1Emc9lARNyA=; b=cWbM0PWZfw1QsRH3SC86X1Juvv3Wih4aW20LK4uoLHX+8MzFHvsK0lHQJ0mU1JYO00 ctYZLlBX+jdtDIJVNzRxOfNJNMOx9ILr4XZlgFD8Srh1KacRLGSPsWZElWdl5d4HzFfw vdnbDZflJVjkwATw0Mjnit+Nf6jYjz3tavFuHqei+ylucc6gc/jwVcamcW2mcnKUw7WP 2CiLaM9Y0H+amxH82Cu2oM10FGKtEd+wl8ECptvkv6Ais7oE8BCh8qkYoIboVu/0XrVx Eys2SthM5BuGHNIq+oyhdTptIoi3JYI7s0cadMH2IuK4KCvVXfwM+aqC5ifhsaZ2wwIb kdVw== X-Forwarded-Encrypted: i=1; AJvYcCU5JOB4jwkZtyKqQla5QnueANviA79r6WxF3WN3Sq6UXoCHMJjypEFq/z6wXUxaNuKlun6diNZrzO7F3MyH@postgresql.org X-Gm-Message-State: AOJu0YxOMhwMm5h8eKRamGaS6MwP2FQffSmWG2tJbuiYtvQrixXAfs4f g8yIbyuKOIiEeZFXqdn+x/agz5r55brdWBejgaEQHyzQvTsq3lsWOQCeF26XI00/r/44HKc3/Pi ZhDim/Fw1RMFqcTODHLAQ9RvHh2OriqA= X-Gm-Gg: ASbGncvQlxW3m3jVN7udJek0qP1wnyySgPzZnslDjFXu8oCJlgRz2RaDSyx1/clmt31 byvR7QswHC1V3OFswzghaMLl//VkKfLK9c8uDAWeuBXogKlg5oYxQHGMG5Hxy8kAS0OZ1wUShS0 jfeqJ2ZO060ysbWVxSMgqvKbWDuBMJjy0LoOgMpf4igZ2cSUA6Lb7l9V/MzOCE5X1R0FnT9j7Tm QllHK5Lz1XY0IO+dtGozL8NAA86Hi+HGMkm/q+MO3ax8PvEqq8Fzj+u2GVl6jGw1+i96bDUuUi2 I/UAt8iCGbYn5ryQW3mc1FyIS/7SmwbppqrUgsNspVoh4gAJ4Uo= X-Google-Smtp-Source: AGHT+IH5fqiFQlot002+Cde98zhR0QqzR2RNKbvEsuaJKYWuHJR9tytW8FPSLIEBpVacqYxkQiLxZNouR7L4Q29NEcA= X-Received: by 2002:a05:6512:3f28:b0:591:ec0d:3014 with SMTP id 2adb3069b0e04-59576e3ed17mr152269e87.48.1762891446943; Tue, 11 Nov 2025 12:04:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Rowley Date: Wed, 12 Nov 2025 09:03:54 +1300 X-Gm-Features: AWmQ_bleru1KW1dFXSuGyco9qcs43eqiaCFlExArBSSl_1Z77CqAl7goeWjwhbs 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 Wed, 12 Nov 2025 at 05:36, Nathan Bossart wrote: > From skimming the latest discussion, I gather we might want to consider > re-sorting the list periodically. Is the idea that we'll re-sort the > remaining tables in the list, or that we'll basically restart > do_autovacuum()? If it's the latter, then we'll need to come up with some > way to decide when to stop for the current database. Right now, we just go > through pg_class and call it a day. I'm still trying to work out what Sami sees in the results that he doesn't think is good. I resuggested he try coding up the periodic refresh-the-list code to see if it makes the thing he sees better. I was hoping that we could get away with not doing that for stage 1 of this. My concern there is that these change-the-way-autovacuum-works patches seems to blow up quickly as everyone chips in with autovacuum problems they want fixed and expect the patch to do it all. That said, the periodic refresh probably isn't too hard. I suspected it was something like: /* when enough time has passed, refresh the list to ensure the scores aren't too out-of-date */ if (time is > lastcheck + autovacuum_naptime * ) { list_free_deep(tables_to_process); goto the_top; } } // end of foreach(cell, tables_to_process) Perhaps if the test cases we're going to give this involve lengthy autovacuum runs, then we might need that patch sooner. I'm uncertain if that's the case with Sami's test. There were some 50GB tables, so I imagine some of the runs could take a long time, especially so when running standard vacuum_cost_limit. David