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 1w7gVd-005asp-15 for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 21:20:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7gVa-00DHac-2O for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 21:20:23 +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 1w7gVa-00DHaT-1K for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2026 21:20:22 +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.98.2) (envelope-from ) id 1w7gVX-00000002Etx-3Ltp for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2026 21:20:22 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5a12cd0bcd8so4880124e87.3 for ; Tue, 31 Mar 2026 14:20:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774992019; cv=none; d=google.com; s=arc-20240605; b=VBrdGWsebk3980NiaSaMfsVDtoBxBqokSlkUbCK/xoewiqYD0JLmvkrFDVVWDwlO7T uplXHjNouy0OqxddPuWchxgBKqScccBGVNySI5mHe+MxN2+yLfmUyWXqE3rvVntmPdsg cGkmq4L2V5WDm1yTo50nq2n3JB44xQBRdCRJaSkg76ExfbilZWvBGqSTrPKHB/DkFhHN W/6Us1wUhLfHE1xVzTqbB5YryPcluDZQiv6KZLsFXY4f0ypNKeoC5PUt2WHQR7r9pPiZ TlOp2qFYvmNtMwXs0tcyZ0RB2kudnZzzg5pigPJDlFM7v3Gv/SwZDcB/xZwMCRTscRNj Wpow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CY2D2Oois4zU6jzn7pmVEm7OAq/pC2uVrfOXlWTC99E=; fh=L2xEDiKrciUDMgj8LQQJeI1+TxFW/2RfPgmVF6bFTe4=; b=VxxIwvGfdsUufprcgDOveoTjouWiJZ+pA2jPER57lEvCfKl9/soL/TEPoLpx3t7Kn5 xTM1jeLa2+7Y7r5J5K75wTPyi0c0lqs7gu4lB2q2K619Z9AclEWRAc/EUwggKXxnaFCB xTfgdE/61fEvwuXuCBeSh9F6X0L0sahiCfJWh5l98iZMCf+kKQj6AkJ/Zc58jXQWZDKt 3ld0gKLmaA1ppv2KHGSkkIRqfpXICwg1lWhpChhRbtVO40UWffuPIP0EbCvOTa3+IPQA rLBBNEQOcWSZ+kfCzzmOKAvy911mFl5YWzM2u6yYDG1tijeSFve+11Es+X1APRgON0Sp y9fQ==; 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=1774992019; x=1775596819; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CY2D2Oois4zU6jzn7pmVEm7OAq/pC2uVrfOXlWTC99E=; b=Is0K8agHMY27e5ysXsR/Yjy1x8OdGzE8zZylJb9MoJCR5xSdDWHBoWEYJZ4ra0keD6 CoOisJJO6RjG7b4nSoxlQXeBM+tt2OZrS6vasvUospNnc6eR/GAp1IsRzKkppzd5lKbW vnUrrHZ8i4UhTlyO9d/+XUn0zGeJb5fP4eXIJOz4JMfmBH3m1TjWfmBDsITPUf8LBlKx fLtadmnEJC9qe2Frn2BNizVrbHUa6M90X/We0hTy7RougqIOb8l22OUYNzM424iQjmCN yP38begYJeW4W8k+6NjHoEwaU/xW8cXhZ6PGct0lLrOH4fOiB23i346CkUReJgfiJbGs vKKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774992019; x=1775596819; h=content-transfer-encoding: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=CY2D2Oois4zU6jzn7pmVEm7OAq/pC2uVrfOXlWTC99E=; b=VmDEJZYyFuF++HYAjXWoXIIqU+xAzfeQBFEPVB1C4KkisR+2we2SwAhQRb/1R70vn1 vwqWxrGy8RrYjQOhcnInUCTywowzYS9Q2kquY/LfznYcrOFSg0r3KmdyFKVy6GuDtFCE InWkgoXvfu4wChiMJa1df1DL5tbg0sUrfhDfzjxs8gb9sT5cx+Xwe9cg8jt7RLcUzDqH vij/X991mUdjGye8iKgtrlMpeoJ9ttF1L2ohXMNaA6lgcKwt3KxYVpa7utFQa4YvL7Oy 8ORg73rUsuOIYeZ4aORezNrmxbEcna3JXdiJ7Op3Q72NPYrg2BkM5mGQy1KjE/FDOZUH WmAA== X-Forwarded-Encrypted: i=1; AJvYcCUs1P+3lQnuQE+TY+QPHtPdC8lfrCb1BB2lHc+5A/sJJcm1CIzLMwJkVWB8Hzzx5oqM3KygLGkWBArMzqoP@lists.postgresql.org X-Gm-Message-State: AOJu0Yw6BQwU6CjucfgGkXSAjpuWRn7a/J5SoLTW5hVpiKqo9CozAWnq xOHR4VylI80q1qcShsaApgZuSl/OoBNflqXp05hHDPkL60ts+56oi7mwq6DJMMN+9Bc8a2wLrWA elxHhhX69uaH6TdqoLBQdKWqbb2shjRo= X-Gm-Gg: ATEYQzxr+3Y+KM46KdwRCXXvmnPDImtTYthsTzUvMPjRZtWog3vo0J8iOgqAGKobvOS sbzGIDdaFQd2RGi+Z0NDHWpM39OfNBAqNgyviYmL0lw1mIxvVeNYQt3UzCIS2wEGfdjQUEABQRN DEjIfJ/0evxjQILEwHgN83Inz8nIwo603YANw4iogRGJsgrtc8ZMArG5bmVq6JtpiSwo5otgrYe HTSQ4vV4L5Rrb9VHlUkM9e4eeVTXXHYcByHNlgbEjxxnRs6GzWltKkQ/dBWjX/47Kr3yCDVXoO6 kEuSoJrHr+CHm60UWgR3jnD5PiO36gibBY/2+iM= X-Received: by 2002:a05:6512:23aa:b0:5a2:ad98:3685 with SMTP id 2adb3069b0e04-5a2c1f3f8cdmr248594e87.35.1774992018806; Tue, 31 Mar 2026 14:20:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masahiko Sawada Date: Tue, 31 Mar 2026 14:19:41 -0700 X-Gm-Features: AQROBzCloBKZXcZOSqaNSdiGakepjI97ac8Tw5F8pieqgELQWSs3DZORaH3Em_c Message-ID: Subject: Re: POC: Parallel processing of indexes in autovacuum To: Daniil Davydov <3danissimo@gmail.com> Cc: SATYANARAYANA NARLAPURAM , Bharath Rupireddy , Sami Imseih , Alexander Korotkov , Matheus Alcantara , Maxim Orlov , Postgres hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Mar 31, 2026 at 7:18=E2=80=AFAM Daniil Davydov <3danissimo@gmail.co= m> wrote: > > Hi, > > On Tue, Mar 31, 2026 at 2:09=E2=80=AFPM Masahiko Sawada wrote: > > > > I've made some changes to the documentation part, merged two patches > > into one, and updated the commit message. Please review the attached > > patch. > > > > Great, thank you very much! > > Again, I don't know how to write the documentation well, so you can ignor= e > my comments : > > > + VACUUM can perform index vacuuming and index cl= eanup > Don't we need to mention autovacuum here too? I thought that VACUUM in th= e > context means "manual VACUUM command". I think that the documentation explains that the autovacuum daemon is a worker automatically executing VACUUM and ANALYZE commands. > > > + ...applies specifically to the index vacuuming and index cleanup phas= es... > Maybe we can refer to "vacuum-phases" here? Agreed. > > All other changes look good to me. > > !!! > > Searching for arguments in > > favor of opt-in style, I asked for help from another person who has bee= n > > managing the setup of highload systems for decades. He promised to shar= e his > > opinion next week. > > I talked to Anton Doroshkevich today. Thank you for sharing! > He confirmed that as a rule there are *hundreds of thousands* of tables i= n the > system, the vast majority of which do not need to be vacuumed in parallel= mode. I'm still struggling to see the technical justification; why would a user want to avoid parallel vacuuming on eligible tables if they have already explicitly allowed the system to use more resources by setting autovacuum_max_parallel_workers to >0? If resource contention occurs, it is typically a sign that the global parameters need re-tuning. As I mentioned, the same contention can occur even with an opt-in style if multiple tables are manually configured. Also, I'm concerned that opt-in style could confuse users since parallel vacuum is enabled by default in VACUUM command. > He also suggested the following : let the reloption overlap the value of = the > GUC parameter. I.e. even if av_max_parallel_workers parameters is 0 the u= ser > still can set the av_parallel_workers to 10 for some table, and autovacuu= m > will process this table in parallel. > > I remember that you want to use the GUC parameter as a global switch, and= this > approach will break this logic. But according to Anton's words, it is oka= y if > the GUC parameter cannot disable parallel a/v for all tables instantly. I= t will > become an administrator's responsibility to manually turn off parallel a/= v for > several tables (again, it is completely OK). Thus, this feature can be ha= ndy > for all use cases. While some autovacuum parameters do override GUCs, those are typically local to the process (like cost delay). Parallel workers, however, are a shared system-wide resource. In a multi-tenant environment, allowing a single table's reloption to bypass the autovacuum_max_parallel_workers =3D 0 limit could lead to unexpected exhaustion of the worker pool. I think that this GUC should act as a reliable global switch for resource management. > I hope it doesn't look like as an adapting to the needs of a specific use= r. > A lot of super-large productions are migrating to postgres now, and I bel= ieve > that we should ensure their comfort too. I'm not prioritizing one specific use case over another. I believe that there are also users who want to use parallel vacuum on hundreds of thousands of tables. We should consider a better solution while checking it from multiple perspectives such as the usability, the robustness and consistency with the existing features and behaviors etc. Regards, --=20 Masahiko Sawada Amazon Web Services: https://aws.amazon.com