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 1vMwSX-006ZyW-1U for pgsql-hackers@arkaria.postgresql.org; Sat, 22 Nov 2025 22:52:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vMwSU-00CjU6-0e for pgsql-hackers@arkaria.postgresql.org; Sat, 22 Nov 2025 22:51:58 +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 1vMwST-00CjTq-2j for pgsql-hackers@lists.postgresql.org; Sat, 22 Nov 2025 22:51:58 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vMwSS-000xch-0k for pgsql-hackers@lists.postgresql.org; Sat, 22 Nov 2025 22:51:57 +0000 Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b472842981fso396216366b.1 for ; Sat, 22 Nov 2025 14:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763851914; x=1764456714; darn=lists.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=7JLzVeOdscKmp5JaDTu9ji3hcw4AsSw3EbHkOdhs0QY=; b=TvtGcrVC53Q/5ZeHpjxOqhrNESw/uSSZweGJxedmDqsu6LZz0kBYydgzDjzN+7S30u EEzIaZip2Hr29MuhxlqcIHeD0m6oaMTyqWTLpt/h4nUEIiF7bs0gE6KOh+0LaD0CfbKF E61Cty90zGvWMEscPbsFzuA64517N74Ud5h2scbV8RGLvBjJ6EYa+PDM0HllADdYSZR6 KowaYvJBgzGRuRrCJ+/21U+/lljKGFfCZe+RPanxZSnZ+Tsk1ZZM5mRtG/MztkGyocR0 87GmJbMKF89sP56tNBy4jzFi0qEKM6IMgikesC+rc5/hzfF4V6oQvgnhahZPHa3CaBX6 Ti0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763851914; x=1764456714; 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=7JLzVeOdscKmp5JaDTu9ji3hcw4AsSw3EbHkOdhs0QY=; b=EV32Njgcp0P+yqHTVyXm1TowOm5bNyGcF3eLju4L14iaJqGS2eyLM2eXNuwNQie1Oo dA0C1Pz2fpmYODOiTlDa9WNECkhS98YVWJv4a/9YWg3gQ9u4FBUEYVPPM/H3aQIsHyim 4Y5vOS3KfQY+85pKRyeiqt0uHSY76Q7tR8Cf1Sjk/pF3CVH1Msag0aI+CPKtm4YPAgQh 9Zx/+V6+eJj8sPX2y9RmMoGjI/2/2GI1exhFqD9wCLxcfRiyu0q02VDqHspZUr29ZLqA 03+iemHK5rCIjd7e/48YETZAtFpZLz6xGgrawAPfoVJ84sFivlryQqNfCFE/ZIyFMoH8 7x4Q== X-Forwarded-Encrypted: i=1; AJvYcCXbmJCnMR/glK7l+aYj39KlmPaidU9lAlpWmVDNJ/WZL9HlxcgOZFvyUiQs8gJxxJ5D/5CpFgJC6hGnP4Td@lists.postgresql.org X-Gm-Message-State: AOJu0YzvhJKVSdAzsKTOflt4v105BIouTVCHuwF/AFlfL9AKsZhUOX7m MjqdaUhReNqUyv0jxwcxgqGgCf3NdEYHkDikAz7nqabo8LAYsfSUzQ3IBsVeEu8gYRwupq9ppHt oNhcEJ9m3YWVH2fZudEeA1WmZwkkTo08= X-Gm-Gg: ASbGncsCIH8H7sUuHH6o3jniwTmT0ju0c7pDoVZNQMWF4e2eCw7K/oRFi5hhJtvwghi dC0V7JIzDvYZIm7OIEinHGYFVckxL4nsG1qoJaGWfYzXWfvTu3mhKSdqAijGwZoIYmJA2u62LUj BriNeORIvNxrUsD2bKrUJdqKMet7YFnQcnXdMeP58ZwVJBnujTy7ixnYkAgZt8R7JuzmhLCGshO +EnFVJYoQ23N9j79pmoQ1rU+6KvMgBcpI91jt8Ogi2m6gfih+3BiKgK4dlQM0CYjVUrtA== X-Google-Smtp-Source: AGHT+IFJ5KqG0KFGTMr3KSJgOF+PfF58YLiOwLwoYJg/r3I2ht68R/Z8Vn5jIvBslki3gZ+H6Xg9CgSFMCmAHJBIDP4= X-Received: by 2002:a17:907:d05:b0:b73:7ca6:220d with SMTP id a640c23a62f3a-b7671a4728bmr748677566b.59.1763851913917; Sat, 22 Nov 2025 14:51:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sami Imseih Date: Sat, 22 Nov 2025 16:51:42 -0600 X-Gm-Features: AWmQ_bkHVq2ozbzoCDCYEPV13TYVDmajyzZbGUBN6XpaUvYVcvOkEBT_9xck_RA Message-ID: Subject: Re: POC: Parallel processing of indexes in autovacuum To: Daniil Davydov <3danissimo@gmail.com> Cc: Masahiko Sawada , Alexander Korotkov , Matheus Alcantara , Maxim Orlov , Postgres hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > > nworkers has a double meaning. The return value of > > AutoVacuumReserveParallelWorkers > > is nreserved. I think this should be > > > > ``` > > nreserved = AutoVacuumReserveParallelWorkers(nworkers); > > ``` > > > > and nreserved becomes the authoritative value for the number of parallel > > workers after that point. I could not find this pattern being used in the code base. I think it will be better and more in-line without what we generally do and pass-by-reference and update the value inside AutoVacuumReserveParallelWorkers: ``` AutoVacuumReserveParallelWorkers(&nworkers). ``` Maybe that's just my preference. >> --- >> { name => 'autovacuum_max_parallel_workers', type => 'int', context => >> 'PGC_SIGHUP', group => 'VACUUM_AUTOVACUUM', >> short_desc => 'Maximum number of parallel autovacuum workers, that >> can be taken from bgworkers pool.', >> long_desc => 'This parameter is capped by "max_worker_processes" >> (not by "autovacuum_max_workers"!).', >> variable => 'autovacuum_max_parallel_workers', >> boot_val => '0', >> min => '0', >> max => 'MAX_BACKENDS', >> }, >> >> Parallel vacuum in autovacuum can be used only when users set the >> autovacuum_parallel_workers storage parameter. How about using the >> default value 2 for autovacuum_max_parallel_workers GUC parameter? > Sounds reasonable, +1 for it. v15-0004 has an incorrect default value for `autovacuum_max_parallel_workers`. It should now be 2. + Sets the maximum number of parallel autovacuum workers that + can be used for parallel index vacuuming at one time. Is capped by + . The default is 0, + which means no parallel index vacuuming. -- Sami