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 1w7Zve-005Sn3-2G for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 14:18:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7Zvd-00AYfo-0c for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 14:18:49 +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 1w7Zvc-00AYfg-2N for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2026 14:18:49 +0000 Received: from mail-yx1-xb130.google.com ([2607:f8b0:4864:20::b130]) 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 1w7Zvb-00000001ynX-1Re7 for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2026 14:18:48 +0000 Received: by mail-yx1-xb130.google.com with SMTP id 956f58d0204a3-6500040f172so8190908d50.1 for ; Tue, 31 Mar 2026 07:18:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774966727; cv=none; d=google.com; s=arc-20240605; b=OKaK57TK64CncrGZxadyzlKA/CMbvlFIo8ZMfYvPIAYzQlsBm3o9MJ92JueUU2HGNa HJ/HabegOBTwOk4u8+Rw4vIgig5rRnfjlrOpQ5hcsO7Xjfe3kMg/ZDHH25uiMotcllAE 0le99N+hEf40j1kWxiXkRpDqFl/hfekDSKk174A0f8zfDpLQ/jGuFc8v0Evx/+w2FUnq 8T7maqjiwpUG9YH94DU3GtuvB1zHf7NV7NUgvOjD7mDvTxvhdwlQuvjynnYyDKfDLrh7 1aB4PneRvBzre/wewsfIpgLVfbLuK8C/0bjaA5pgM0yTobR9wfA8Bt2I7JfQ1LU3UvuC 8azQ== 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=GmZTwu0laiQ6DFy4x+gSqDkcGF+ttk3rI2HzYab5Tu8=; fh=lHybA5jKapf0cv+HjOUabR/qVvfqg7Bd7uxXiV+1xjs=; b=aajHD5i7GI7IjGZ+Poy9ZXCgQnZphs7Ydb/O527omn6c7FFSv9VLWnCMW233+fX/dl sF8qHmTd+ZBZk8CCFcmUMyBIgmuyPb24GNPB+a2m3+vxEgnhJMoqJFbfOZ16NvbjpZ2T w2X69AhoJdpvCLm4ZlI8Ai2JP04X5ZZfLhcviE0ZIUP9CuzO6OnFZnqtDDBe4AWTI3z2 nFsKeCV9EciSo0zDDFS6MnFRKsLa5vWVasnPxd8yMfgcLGwm7gi/54Zly6eSSO8//E79 Rkk/hfFomOuGXppqQZual5DgOsFxwuSyHcN0Pmmu2iy1CCLgSVvP/QvRHwVo+OQ4BU2f am9w==; 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=1774966727; x=1775571527; 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=GmZTwu0laiQ6DFy4x+gSqDkcGF+ttk3rI2HzYab5Tu8=; b=KV4LzJHi9GCUDj6I7TQZRvPidj6LWh39MU5CBvs9mK3l6sn0xbNvure6cSBdVVqnw8 Nhtc9jkZfW41r3it6jTfqR+qIEEzh14Pgv1ebj+tPiOZPqmD6QfxZCgzBYjEfLUcNNwJ YaMrEhlIaG9S+vDq2gIhJjcx/uBjK31GdDBz67svDecN8GUNf+L4jKLfXcB8wuNF29NL ObMH5fsCBsIKhIiHwrFjRvhayP4sBjtiRAVnSvdWwlm0zuUujinzr78NCpCCPjlHJ8Jc WQOGgytx8umoKHjSdVRjj4N5ObDNi7xr4u3PjTn10A4HilxVs23iOfzITXq8zQpT5r31 DARg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774966727; x=1775571527; 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=GmZTwu0laiQ6DFy4x+gSqDkcGF+ttk3rI2HzYab5Tu8=; b=Jjezz9N7XKmfjcVN/W4/8TBC3lHFRb98vYe1gbRN0mUgr6KeIMuN3972/YZMiq41c0 8R1ZYtrK2Qv3xzVHVElIeD5TA0Cnc4uC4xkePjXuQpjrldYQr1EhbNeY1N47aJuo6rxD h6WdkzEBK7XdAM5g/MaVFZiB99WZdkC9RLECKcfev3iYgskuiu3Pr5A6thPEMuGYZhWO 9286I7CPVY/IlemE6FePzwNGX/HwBUL896/shdfHJfDOlgI4I422+hIFHPtE0JUPN5p+ ho6Kxd51UIXD0FJRwSClN+k5oyxDOIBuWQpd4gfgKYznGIUfd9qqf47QaRpj51EfCRd3 Rrmw== X-Forwarded-Encrypted: i=1; AJvYcCXIQwpXVUFTKQQ3oE9ndjWRke2IW87vADfLv8DBz5TfPMySOk4qs+SdGo6o16vexA1L9igR82j/+g5hZggW@lists.postgresql.org X-Gm-Message-State: AOJu0YywO7aN89gRBIMvldeOiYANLR8lcfchm07exfN32u5Wvk/izcZO 8zhZfAs2X+YcZS7tKtreZCykjMT3iKfIEVLhO6oMXVATxUrISfC93smFcfKSMmwrXqBPbFT/Z+D 3w+NYWMdAWfVdiDkApAm/TVqP5bY/9FQ= X-Gm-Gg: ATEYQzxXE5lR6aWGSWsyI1q9AaB2yzJi/37qNQNjyVmI8ZZuu+eWYlGbuFcU/OSvfVR IXJE/j8wXLDceOax0yMHFD2/7mQ8Aogyn+xhjh9keWaUHvCb/wGRMOxg4rkhj+l0U/123BycTq3 ZghoHuPm1NkdFjdJaKd5U4oX9sj+/zzXS1Ow26+ejjBIQ0nrGW2jHVEaSSnRJ2S/p1gjSbG5eiL K2jVwIoid6T31iuJNk+yVWZOCROwYX5nWW62+tgBSRY1/zo3panAz83NobP95hO8YppSwMkHjBb Wj2S+8lS X-Received: by 2002:a05:690c:389:b0:79a:cdf0:e27d with SMTP id 00721157ae682-79bde1264b8mr162383397b3.55.1774966726614; Tue, 31 Mar 2026 07:18:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniil Davydov <3danissimo@gmail.com> Date: Tue, 31 Mar 2026 21:18:34 +0700 X-Gm-Features: AQROBzDYf82zScfLLdxo5misAiaLzjafCuV0WRSceMNNq6D_94VAXnwZ0uDnP2A Message-ID: Subject: Re: POC: Parallel processing of indexes in autovacuum To: Masahiko Sawada 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 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 ignore my comments : > + VACUUM can perform index vacuuming and index clea= nup Don't we need to mention autovacuum here too? I thought that VACUUM in the context means "manual VACUUM command". > + ...applies specifically to the index vacuuming and index cleanup phases= ... Maybe we can refer to "vacuum-phases" here? 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 been > managing the setup of highload systems for decades. He promised to share = his > opinion next week. I talked to Anton Doroshkevich today. He confirmed that as a rule there are *hundreds of thousands* of tables in = the system, the vast majority of which do not need to be vacuumed in parallel m= ode. He also suggested the following : let the reloption overlap the value of th= e GUC parameter. I.e. even if av_max_parallel_workers parameters is 0 the use= r still can set the av_parallel_workers to 10 for some table, and autovacuum will process this table in parallel. I remember that you want to use the GUC parameter as a global switch, and t= his approach will break this logic. But according to Anton's words, it is okay = if the GUC parameter cannot disable parallel a/v for all tables instantly. It = 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 hand= y for all use cases. I hope it doesn't look like as an adapting to the needs of a specific user. A lot of super-large productions are migrating to postgres now, and I belie= ve that we should ensure their comfort too. What do you think? Can postgres have such a logic? -- Best regards, Daniil Davydov