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 1w5IwF-0036zY-1M for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 07:46:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w5IwD-00Cmzw-2W for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 07:46:02 +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.96) (envelope-from <3danissimo@gmail.com>) id 1w5IwD-00Cmzd-1E for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2026 07:46:01 +0000 Received: from mail-yw1-x112b.google.com ([2607:f8b0:4864:20::112b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from <3danissimo@gmail.com>) id 1w5IwB-00000000vlW-3uyC for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2026 07:46:00 +0000 Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-79ab5fd969aso33177357b3.0 for ; Wed, 25 Mar 2026 00:45:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774424759; cv=none; d=google.com; s=arc-20240605; b=i3MmU5La4xM1njer8+GZ29a0tShhSQgOS/44RXfBVh4LvxCSFo+DCa7rRIo0r6VZ7l NpOf1WPIzTDxFl5gQckKOEDpU7foZ0JYxUzMrqVcmUOHQa9Fn6BBIsYK43EsL1VixpiN oYqxrF6HAv80JgTvcBKQtXbSdwL8sCfmNN5FudY74zgYdZlOdnn7jVGaleAhSVIpTt1w 33yunZ5RE4xpoeukCQEVzW0XpqIumXqokLzISAg2K8iQwypDYqhGZIQRrPR6USVdzge3 J2pYGbtVhZz5/bTZorikTfUI+Z5FPIQdiT7qx968XeFldcnQzKBaXPb9HgN83JG/H2li Xo4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=INdK5BJx3KnDoiuU4J44FHuVf7VlZDjg25DSmsoGdCM=; fh=qsoTaZPOcC1jlwFy8ni8w0K3+5ZLPCvlBcpTJs2FUDE=; b=f2MGHn1DSAeI4nR7Sjm1Ul5Ob9b497C0/nipRPGiwnrSXzsxZqOS+8mxh+marUBl9W VYcrmR9rSoW4fYCOkeV9bE0miRF5mbmQwgq6zmEBguCXo1rQzLnt4f8dWvwU9oWaR1Ow olL9ePvCkK/KhMGQXS35kmHlMsoB1Pk8VbfSx+WDMJ+DFLdkMlk2bSnlVM9v4tylZe8q he98tTLPTXy7N5TTmxfO89I6IflzEkzO5FNZh04bFDKmrJTt7Ry5bGUKS43IVTvUtHru mLGXjazWrhOr2WFFdB6CsSIJnADsnsyREKMBU29HXvkddTxJCJt/4nexYuJqRpZQkgbM sbhw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774424759; x=1775029559; 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=INdK5BJx3KnDoiuU4J44FHuVf7VlZDjg25DSmsoGdCM=; b=Jr6jzoWzqI2lLzDm+UII+YhAMdQetuwiotjoc6wq6gYSNDRb6r/wwRFpMNW44+G1u9 7YvMeUWZpkeeLIjIR5laXbr6OTctn5At180Wu3ppSOcpe8AFoaa4Sh/qckr956oXQlQb OJxXZSJkkL3MEHOj+hgZHHTB5brfjd6hM4WMi041C8BGu8N/oug0diDAzoUAZj1RqJQL Zm+msBS/QJTODjDwiP8l0S16KimpDkPYtHNtCOgnLvR8iP2hgwyW039CFMYfydbNTTWx tiIP2NCpkNVrPsThfzsouTm1aJfCJcPjWPg6blyiQ+frv30/vk+PMrJounw+VFkSTxgN Y/Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774424759; x=1775029559; 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=INdK5BJx3KnDoiuU4J44FHuVf7VlZDjg25DSmsoGdCM=; b=Ou5NYxvm7OaosdhIvbXhoFRvzv0ITjsPNN/8tyh8k7ZJ1BWlwC3Vth8SrcFhmh+3vi Q0bSvi0rWJ7ehK3Ty2w12VGk+tzzSmc1wteYWGD+cQapxDyernSO4kMM8XzgjhtucclB fLLy8BzeeDzVJ29yE09kGjplSui3+mEey9rwxhsrI+lUw1rhvAJkd+yrwGV38/8dKTba 1DvZ9OL99j4l1iSw4KJFMxTHEIHmRs021Smx8T8tyX0swKI8B8j+uou2iN71Bl8kCYS+ r+NjpHTpEAWJ5INk1ywqg6+BMC42PaDQbQb7ek+A4W4/haRn9naupkXCKPZpCoyTFeW8 lNUg== X-Forwarded-Encrypted: i=1; AJvYcCVB078/pRP/jLxMgRE91NOdtrC/e6qmjH9WdHYHf6kXGv+9RrmX+kJSr/WiQVTybgnpil8d55c+2Dj7FJDX@lists.postgresql.org X-Gm-Message-State: AOJu0YzlDqsFIkzR3122mSxb2PsdoFxzpixXM6+Ko4ughfJ34ANOTdYh Mrj8/DNnSMfRVIxmDfxOWFK6bEnjdDVBjsDL016AhSEmkjN1bphJrmg9UbC8o/QpJBUCvqpWSKC x1TT0xK0cXPukFVz1n3JIsZ7B8sT+5o4= X-Gm-Gg: ATEYQzybG+qxCKLGTIuSSaELg8NGCtWPmAIq95jbPlIHsnJkz9mpNQF3bOp2M1uEO6i 942FucqMMEk+ueSSv/4Isq5yVXpXmD1mH+W18ka9s1ecFS2pQU3w8xbiK4Snr4r3i21UrjepOS+ 9f36uc+Icp9Lxs/KRiBxKJwv/mk0daD2BsTmmzt5Xpd9DVp3koRNj/9S37PbedXC89NOESu9DlC 93RjitBSvV/mlhvl12SV06Lq+7o+vAuFAP0vby8JPe6fO5wT8R2xKeUlSdf3mvYtJOdmDKre235 4ATh0mTz X-Received: by 2002:a05:690c:89:b0:79a:7e0a:57e7 with SMTP id 00721157ae682-79acf612611mr25959877b3.37.1774424759260; Wed, 25 Mar 2026 00:45:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniil Davydov <3danissimo@gmail.com> Date: Wed, 25 Mar 2026 14:45:47 +0700 X-Gm-Features: AQROBzCrwRg1QYZVFy9URsLgGKGhAN_5W9oMQwKuCi5dN-tSlpF_34f8wLFwtF0 Message-ID: Subject: Re: POC: Parallel processing of indexes in autovacuum To: Masahiko Sawada Cc: Sami Imseih , 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 Hi, > > Yeah, currently user can misconfigure max_parallel_workers, so (for example) > > multiple VACUUM PARALLEL operations running at the same time will face with > > a shortage of parallel workers. But I guess that every system has some sane > > limit for this parameter's value. If we want to ensure that all a/v leaders > > are guaranteed to launch as many parallel workers as required, we might need > > to increase the max_parallel_workers too much (and cross the sane limit). > > IMHO it may be unacceptable for many systems in production, because it will > > undermine the stability. > > I understand the concern that if max_parallel_workers (and/or > max_worker_processes) value are not high enough to ensure each > autovacuum workers can launch autovacuum_max_parallel_workers, an > autovacuum on the very large table might not be able to launch the > full workers in case where some parallel workers are already being > used by others (e.g., another autovacuum on a different > slightly-smaller table etc.). But I'm not sure that the opt-out style > can handle these cases. Even if there are two huge tables and users > set parallel_vacuum_workers to both tables, there is no guarantee that > autovacuums on these tables can use the full workers, as long as > max_parallel_workers value is not enough. > I guess you mean the "opt-in" style here? Sure, even opt-in style doesn't give us an unbreakable guarantee that huge tables will be processed with the desired number of parallel workers. But IMHO "opt-in" greatly increases the probability of this. Searching for arguments in favor of opt-in style, I asked for help from another person who has been managing the setup of highload systems for decades. He promised to share his opinion next week. > > > > BTW, do we need to mention that this parameter can be overridden by the > > per-table setting? > > IIUC the per-table setting is not actually overwriting the GUC > parameter value, but it works as an additional cap. For instance, if > autovacuum_max_parallel_workers is 2 and autovacuum_parallel_workers > is 5, we cap the parallel degree by 2, which is a similar behavior to > other parallel operations such as the parallel_workers storage > parameter. BTW it actually works in a somewhat different way than > other autovacuum-related storage parameters; the per-table parameters > overwrite GUC values. I decided to use the former behavior because > autovacuum_max_parallel_workers can work as a global switch to disable > all parallel autovacuum behavior on the system. > Yep, you are right. I am misworded. Let me reformulate my question : Do we need to mention that this parameter can be capped by the per-table setting? > > > > Part 3 can briefly mention that autovacuum can perform parallel vacuum > > > with parallel workers capped by autovacuum_max_parallel_workers as > > > follow: > > > > > > For tables with the > > > storage parameter set, an autovacuum worker can perform index vacuuming and > > > index cleanup with background workers. The number of workers launched by > > > a single autovacuum worker is limited by the > > > . > > > > I suggest adding here also a description of the method for calculating the > > number of parallel workers. If so, I feel that this part of documentation will > > be completely the same as in VACUUM PARALLEL (except a few little details). > > Maybe we can create some dedicated subchapter in the "Routine vacuuming" where > > we describe how the number of parallel workers is decided. Lets call it > > something like "24.1.7 Parallel Vacuuming". Both VACUUM PARALLEL and parallel > > autovacuum can refer to this subchapter. I think it will be much easier to > > maintain. What do you think? > > Describing the parallel vacuum in a new chapter in section 24.1 sounds > like a good idea. OK, then I'll do it. -- Best regards, Daniil Davydov